geteilt von: https://lemmit.online/post/3018791
This is an automated archive made by the Lemmit Bot.
The original was posted on /r/ProgrammerHumor by /u/polytopelover on 2024-05-26 21:23:20+00:00.
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.
No fiting. IS always goes at the start of names for booleans you are correct
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
does ‘?’ have type definition in elixir or this is generally agreed design pattern?
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.
I am a programmer, and i also like the naming scheme on the right
Especially for things like filenames
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
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.
We probably have slightly different work processes.
I’m more likely to be making “foo” functionally complete and then making “bar” complete than I am to be making all my dialogs functional then all my tabs/whatever.
This comes from TDD where I’m making a test pass for “foo”, once done, I’ll do the same for “bar”.
Though it’s even more likely these are different files entirely, rendering the arguments moot.
Where’s file_dialogue_open
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
If I were designing a natural language, I’d put adjectives after the nouns, so you start with the important things first
So - French?
The thing is that in French, Spanish, etc. it still makes sense if you put the adjective before the noun, even if it might sound weird in some cases. An adjective is an adjective and a noun is a noun.
But English is positional. Where you put a word gives it its function. So “red car” and “car red” mean different things.
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 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.
