new preference war just dropped

First one are method name, second one are status name.


def open_file_dialog(self):
       self.dialog_file_open = True
       pass

Yoda level preference war.

I tend to add is to booleans toreally differentiate between a method name and a status.

def open_file_dialog(self): self.dialog_file_is_open = True pass

That way, it's easier for my dumb brain to spot which is which at a glance.
- is_dialog_file_open
  
  fite me
- In Elixir, we mark statuses by using a question mark at the end of the variable name. Something like this:
  
  authorized? = user |> get_something() |> ensure_authorized?()
  
  I like this better than the is_ prefix
This is the way.

Command statement = an action

Question statement = a status
Lol mutable state

There is a reason why little endian is preferred in virtually 100% of cases: sorting. Mentally or lexicographically, having the most important piece of information first will allow the correct item be found the fastest, or allow it to be discounted/ignored the quickest.

That's actually filtering not sorting.

That being said, it's more valuable (to me) to be able to find all my things for a topic quickly rather than type.

Foo_dialog

Foo_action

Foo_map

Bar_dialog

Bar_action

Bar_map

Is superior IMHO.
- If you are looking for Bar, it is highly likely that you are already looking specifically for a particular functionality - say, the action - for Bar. As such, it is irrelevant which method you use, both will get you to the function you need.
  
  Conversely, while it is likely you will want to look up all items that implement a particular functionality, it is much less likely you are going to ever need a complete listing of all functionality that an item employs; you will be targeting only one functionality for that item and will have that one functionality as the primary and concrete focus. Ergo, functionality comes first, followed by what item has that functionality.
- I put all those in different files
  
  compont/functions/foo.ext etc.
But also, sorting big endian automatically groups elements associated with common functions making search, completions, and snippets easier (if you use them). I'm torn
I was going to write something like this. You actually wrote about semantic order, but syntactically it is as much important e.g. it is easier to sort dates such as 2024-05-27 than 27.05.2024 in chronological order.

I'm truly torn with this. The first one seems sensible (action -> target) and easier to read and reason about (especially with long names), while the other one looks more organized, naturally sortable and works great with any autocompletion system.

We need a new framework, one that allows universal lookup, and makes life easier

x = _.dialog.file.open y = _.open.file.dialog z = _.file.open.dialog a = _.file.dialog.open

Once done, the formatter simply changes everything to _.open.file.dialog

Let's get this done JS peeps

\s
- Aahh you can't just make this problem object oriented!
  
  C programmers don't like that.
- Insert xkcd about 15th format

Where's file_dialogue_open

We're all trying our best to ignore the Americans and you bring up m/d/y... why!
This is the real big-endian way. So your things line-up when you have all of these:

file_dialogue_open file_dialogue_close file_dropdown_open file_rename directory_remove

If I were designing a natural language, I'd put adjectives after the nouns, so you start with the important things first:

car big red

instead of

big red car
- literally spanish lol
- If I were designing a natural language, I'd put adjectives after the nouns, so you start with the important things first
  
  So - French?
- Heathen! You must alphabetize all the things!
  
  Like seriously. It makes scanning code much easier.
To be fair, it's also missing open_dialog_file, dialog_open_file and most crucially file_open_dialog

I prefer everything to be how you would read it as text. So create_file_dialog it is. Honorable mention is to have it namespaced in a class or something which I think is best. file_dialog.create or dialog.create_file or even dialog.file.create

My method names are the same way but I aggressively sort things into modules etc so it comes out the other way.

But if I was staring down dozens of these methods and no way to organize them, I'd start doing the sorted names just for ease of editing. L
I agree. I say open door so the function should be named openDoor.

Honestly nowadays none of that matter if you're using any remotely modern IDE with good indexing and a sensible search, you can start typing however you mind works and it will find it no matter how it's named.

I do one, the other senior dev does the other. We fight about it in pull requests.

Your team needs to have a coding standards meeting where you can describe the pros and cons of each approach. You guys shouldn't be wasting time during PR reviews on the same argument. When that happens to me, it just feels like such a waste of time.
- Preachin to the choir, friend. I'd get worked up about it but I'm paid the same regardless of how upset I get.
- Or they need to kit car about stuff like this since it probably doesn’t actually matter.
This sounds like the typical plot of a story from The Codeless Code.

Edit: How about this story specifically?

Variety is the spice of life.

Mmmmmmmm... Lexicographical Endianness.

the people who chose the first one...who hurt you?

I will
No one, it just makes sense.

You must be one of those "Throw your mother downstairs, the box of tissues" types.

Yoda sounded normal to you I bet.
- It makes sense until you write 30 methods to manipulate the data layer.
- reverse polish notation time
Powershell

I used to like the action followed by direct object format, until some time ago when trying to find methods or variables related to a specific object. If the action comes first, scanning for the object without an IDE means first reading unnecessary information about the action. That convinced me to opt for $object-$action in situations where it makes sense.

For example in CSS, I often scan for the element, then the action, so $element-$action makes more sense. BEM kinda follows this. When dealing with the DOM in JS, that makes sense too button.fileDialogOpen(), button.fileDialogSend(), ... makes more sense when searching.

Of course one has to use it sensibly and where necessary. If you are writing a code that focuses more on actions than objects, putting the action first makes sense.

A similar thing is definition order.

def main(args):
  result = do_something(args.input)
  processed = process_result(result)
  transformed = transform_object(processed)
  return transformed.field

def do_something(some_input):
  ...

def process_result(result):
  ...

def transform_object(obj):
  ...

I find this much easier to follow than if main were defined last, because main is obviously the most important method and everything else is used by it. A flattened dependency tree is how these definitions make sense to me or how I would read them as newbie to a codebase.

Anti Commercial-AI license

I agree with you especially on the definition order of functions. I, too, define main() first.

Be php, mix and match

let the chaos reign

I worked at a place where all the DB column names were like id_user, id_project. I hated it.

I didn't really care about this thread until I read this comment.
I worked on one where the columns were datanasename_tablename_column

They said it makes things "less confusing"

First of all, it's spelled dialogue

Two wars can exist simultaneously.
OP's username is in German, so it's probably half-German-English code
- Germans learn UK English

I personally prefer dialogs.FileDialog.open()

Powershell has a lint warning for functions that don't follow Verb-Noun format, and verbs here are a list of approved verbs lol

I just name my variables a, b, c etc. If I have more than 26 variables in any given function, I name them aa, ab, ac, etc.

you're on a highway to hell.

Whatever is more useful goes first.

For example, if this we're a list of UI text strings, finding all of the dialogue options together might be useful.

If, instead, this is a series of variables already around one dialogue, then finding the open or close bits together would be useful.

A third option there is

A fourth there option is
open_dialog_file or dialog_open_file?

Yes.

Both:

dialog_error = Dialog_plain.create_modal(error_text)

Variable and class names go from more general to more particular, functions begin with a verb.

Global functions are either "main", or start with one of "debug", "todo", or "shit".

The object/class/thing would normally be its own class file, the action would be a method/function of said class.

Ie:

fileDialog.open()

fileDialog = Class (Dialog), Subclass (FileDialog)

It’s referring to variable names. For example, you have a variable named fileDialog. I would prefer to have that named dialogFile.

Create a file handler class to avoid the issue

Eww, that’s OOP
- Meh, a class is just a struct of function pointers.
FileDialogFactory

I don't know and that's the problem :(

I keep asking myself what to choose, only for changing it a day after cursing myself to choose a stupid name.

Big endiant is great for intellisense to quickly browse possibilities, since it groups it all in the same place. But that's also a detriment when you know what you want. You can start typing without the prefix but you'll have to go through the better suggestions of intellisense first.

Little endiant is the same thing, but in reverse. Great when needed, but bad for browsing.

Although I do have some fix I'm starting to use. But it's not applicable everywhere, and not in every language.

What I do is use module as prefix. Instead of dialogue_file_open, I create a file_open in the dialogue module, allowing either directly calling file_open, or dialogue::file_open. Using intellisense on the module allow for easy browsing too!

Although in OP's post I'd rather have file_open_dialogue as it convey the more significant meaning, being to open a file, first. Then "dialogue" is just the flavour on top

Big endiant is great for intellisense to quickly browse possibilities, since it groups it all in the same place.

If only someone would train a program… we could call it a Large Language Model… to knowingly group the names together so we wouldn’t have to choose between human-readable format or dB format.

Guess that will never happen because instead we’re stuck using “AI’s” to inflate stock prices instead. /s

I remember seeing a proposed language that would allow each programmer to choose what name to use for each item. Don’t like ‘open_file’? Choose to see it as ‘file_open’ every time you review the file in the future.

While we battle with each other endlessly, we keep forgetting that the computer doesn’t care.
For me it's simple.

Pseudo-OOP in C which takes dialog* as a forst argument? dialog_open_file

Otherwise - make it human readable

I know I'm late to this but here's my (probably insane?) take. We use Subject-Verb-Object in English right? So, hear me out:

dialog_create_tab(...)
dialog_open_file(...)
dialog_close_file(...)

Romance language word order noun_descriptor is the right way.

in general, adjectives and verbs after nouns because it's more organized/easier to search/filter. as god intended.

As a rule of thumb, I always put action verbs at the end of method names

We just call those Smurf names.

Not new

I have never thought about it

new preference war just dropped

This is an automated archive made by the Lemmit Bot.