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 passYoda 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 passThat way, it’s easier for my dumb brain to spot which is which at a glance.
is_dialog_file_open
fite me
No fiting. IS always goes at the start of names for booleans you are correct
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.openOnce done, the formatter simply changes everything to
_.open.file.dialogLet’s get this done JS peeps
\s
Insert xkcd about 15th format
deleted by creator
Where’s
file_dialogue_openWe’re all trying our best to ignore the Americans and you bring up m/d/y… why!
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, theaction- forBar. 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 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(...)I worked at a place where all the DB column names were like
id_user,id_project. I hated it.I worked on one where the columns were datanasename_tablename_column
They said it makes things “less confusing”
Be php, mix and match
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.
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.
the people who chose the first one…who hurt you?
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.
