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.

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.

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.

Where's file_dialogue_open

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

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

Can't remember which is which but if it's organized in a top-down way (broad category first) that's just easier to look at and find stuff in the file system. I don't want to have to actually read and mentally process the names of every single file to figure out if it's the one I need. Sure, the "human readable" names are fine and good when you don't have hundreds of them you're trying to look through, but big projects I find are way easier to parse with the category naming.

Variety is the spice of life.

Mmmmmmmm... Lexicographical Endianness.

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

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

Be php, mix and match

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

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

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.

I personally prefer dialogs.FileDialog.open()

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.

A third option there is

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".

First of all, it's spelled dialogue

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)

I know the second one is better, but I also know I'm terribly inconsistent with this stuff.

dialog_file_open_dialog I prefer big.LITTLE cpus

Create a file handler class to avoid the issue

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

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.

I have never thought about it

Not new