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.
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.
Tha 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.
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.
I put all those in different files
compont/functions/foo.ext etc.
Depends on the language’s constraints, but yes: more smaller files please!
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 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.
Agreed. This type of fun is good for the team. Trying to stamp it out, when it impacts very little, is just a buzzkill to the team.
This sounds like the typical plot of a story from The Codeless Code.
Edit: How about this story specifically?
As a rule of thumb, I always put action verbs at the end of method names
Yes.
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(...)First one are method name, second one are status name.
def open_file_dialog(self): self.dialog_file_open = True passLol mutable state
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
that works for 2 word names eg is_open or is_file, but in this case is_dialog_file_open is structured like a question, while dialog_file_is_open is structured like a statement
It still works. is_this_thing_some_thingy. Is is just a prefix for if the suffix returns true/false.
Doesn’t matter, the point is that, if it starts with “is” then you automatically know it’s a boolean.
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_prefixdoes ‘?’ have type definition in elixir or this is general agreed design pattern?
If it’s like Lisp, then
?is just part of the symbol and doesn’t have any special syntatic meaning. In different Lisps it’s also convention to end predicate names with a?or withP(p for predicate)
jealously weeps in ruby
We do this in Ruby all the time, we just prefer methods over variables, usually.
def authorized? current_user&.authorized? endI’m a principal backend engineer routinely writing Ruby for my day job, so I’m familiar, lol. But you can’t do it for local variables and that just sucks. Definitely a +1 for Elixir.
This is the way.
Command statement = an action
Question statement = a status
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.
Where’s
file_dialogue_openThis 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_removeIf 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
Heathen! You must alphabetize all the things!
Like seriously. It makes scanning code much easier.
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.
And “red big car” is wrong.
That’s because they are romance languages. They come from Latin where word order is irrelevant as each “word” has a different form for the specific use.
Yes, that’s what I said. My native language is a romance language too. And after speaking it her whole life, my wife has trouble getting the grasp of how in English swapping two words completely changes the meaning of what she’s saying (especially when it’s two nouns, like e.g. “parent council”)
We’re all trying our best to ignore the Americans and you bring up m/d/y… why!
To be fair, it’s also missing
open_dialog_file,dialog_open_fileand most cruciallyfile_open_dialog
Romance language word order noun_descriptor is the right way.
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.
Be php, mix and match
let the chaos reign
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
Dialogue is UK English. But I just looked it up and apparently ‘dialog’ is a computer term, but should not be used on its own but rather in combination, such as ‘dialog box’.
Americans sadly got there first and defined all the computer terms, that’s why it’s a TV programme but a computer program. I can deal with that though, helps distinguish computer things from real things!
the people who chose the first one…who hurt you?
I will
Powershell
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.
Mmmmmmmm… Lexicographical Endianness.
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 afile_openin thedialoguemodule, allowing either directly callingfile_open, ordialogue::file_open. Using intellisense on the module allow for easy browsing too!Although in OP’s post I’d rather have
file_open_dialogueas it convey the more significant meaning, being to open a file, first. Then “dialogue” is just the flavour on top
