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

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.

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

Create a file handler class to avoid the issue

Romance language word order noun_descriptor is the right way.

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

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(...)

We just call those Smurf names.

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

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

Where’s file_dialogue_open

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

Variety is the spice of life.