Is the George Orwell who i am thinking?
How to name things in programming
71–80 of 177 posts
Re: How to name things in programming
#72Earlier quoted context omitted.
Imagine Ritchie & Thompson would have taken the above advice and named ++ operator "increment(x)". That would suck in a big way.
I know you jest but I can actually see some advantages to not even having a ++ (and a --) operator. You already have '+1' and '-1' so it's not even shorter (and those can't be sneakily inserted into expressions leading to side effects of the expression other than the value computed) and the post and pre-decrement versions of that can lead to very subtle bugs.
Re: How to name things in programming
#73I agree with everything except abbreviations, but to be honest, I think my worst habit it just trying to use words with the same number of characters for different variables so they align well with monospace font. e.g. int num = 42; int acc = 0; instead of; int n = 42; int acc = 0; and it gets worse when things get complicated; vector dist; // stands for distances vector excs; // stands for excesses Does anyone else…
int n = 42; int acc = 0; Fixed Edit: Install http://wbond.net/sublime_packages/alignment and add this key binding `{ "keys": ["ctrl+shift+a"], "command": "alignment" }`.
To someone who views this as a table, the above is so much more readable that it doesn't even bear thinking about. To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop. What the hell are you doing with n? Oh, if I look far enough, there is an assignment there.
Very likely you will see what I've written and find it incomprehensible because you have never looked at an expression the way I do. What's worse is that there isn't just 2 ways to look at it. Coding style purists usually don't realize that they are simply fooling themselves into thinking that their way of looking at something is optimal for everyone.
As someone else mentioned, the day when we can express how we want our code formatted and our editors will instantly format it that way (for everyone) can't come soon enough. But until then, it would be best to simply realize that there is no "best" way and that you should go with what the majority of the team likes, no matter what you personal preference is.
Re: How to name things in programming
#74An important rule is missing here: variables should be named with their scope in mind. So if a variable is longer lived and has larger scope its name should be that much more descriptive because when you're looking at it the only thing that will tie the value of the variable to the context within which it can be used is its name. So 'i' is fine for a loop control variable with a scope of five lines but totally inadeq…
sorted(pairs, key=lambda p: p[1])
Though in that case you might prefer using the operator module. sorted(pairs, key=operator.itemgetter(1))
The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously.Re: How to name things in programming
#75An important rule is missing here: variables should be named with their scope in mind. So if a variable is longer lived and has larger scope its name should be that much more descriptive because when you're looking at it the only thing that will tie the value of the variable to the context within which it can be used is its name. So 'i' is fine for a loop control variable with a scope of five lines but totally inadeq…
Correspondingly, some objects don't need names at all. sorted(pairs, key=lambda p: p[1]) Though in that case you might prefer using the operator module. sorted(pairs, key=operator.itemgetter(1)) The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously.
pairs.sort_by(&:last)
No need for defining a block and naming its parameter either.Re: How to name things in programming
#76Re: How to name things in programming
#77Slide 41: "If you don't know what a thing should be called, you cannot know what it is. If you don't know what it is, you cannot sit down and write the code." A few years ago, I programmed in Max/MSP (max4live, technically) for a while and one thing I found super-refreshing is the ease at which you could prototype and experiment your way to a solution just by not having to figure out what something should be called u…
I agree, though there is a difference between being able to explain something and naming it. I've been known to forget the word "door", but I could quite happily explain how it worked.
And I guess this is exactly why author wants programmers to learn from the masters of spoken langauges-- ability to use the right word(s) to explain the concept/abstraction/property/behaviour/type.
If one is unsure about how something works, then more often than not one would end up naming the thing wrong. By far and large, the most frustrating thing I've come across during code-reviews is generic names assigned to vars like 'buffer', 'arrays', 'queues' and so on... and SQL table names that have no relevance to the data being stored in them. It is a constant struggle to read and reason with such constructs. So if you know how something works, you are oblidged to name it approp.
Douglas Crockford in his 'JS: The Better Parts' talk at JSConf 2014 spoke about three responsibilities a developer must have:
1. Make life of people using the software better and to not frustrate them, humiliate them, hurt them, confuse them.
2. Make life of people maintaining/developing the software better . To not check-in cruft, bloat, and errors. Write the best code, and to not make anything worse.
3. Make life of people managing the business/development easier.
Re: How to name things in programming
#78The author states: "Most of the things programmers say about comments in code are excuses for not writing any comments at all" This is true. Here is my excuse: 1. Follow all rules for writing good comments 2. Comment is now short, crisp and concise 3. Apply "Extract Function" refactoring, use comment as function name 4. Your comment is a compiled entity now 5. Write testcases for the function that explicitly explain…
Comment-less code is not a virtue. Useful comments that describe the "why" (but not the "what" or "how") of code are a virtue.
Re: How to name things in programming
#79One Clojure style guide actually recommends [0] certain single-letter names for input parameters: x and y for numbers, n for an integer, s for a string, f (and g and h) for functions. These are used in the clojure.core namespace, and their use elsewhere is thus (presumably) justified by a general common understanding of their meanings. [0] https://github.com/bbatsov/clojure-style-guide#naming
Interestingly, functional programming leads to a different naming custom that this presentation didn't really cover. To write "functionally" you want to have pure single-purpose functions and the name is supposed to describe exactly what the function does. If you can't write a short enough function name then your function is probably too long and should be broken up into functions that can be given concise names.
Another interesting functional programming naming custom is that a function that transforms data (fully FP) should describe the final result rather than the action of changing it. So if you transform a string to json, the function should be simply called `json` rather than `string-to-json` or `json-parser`. This is because when reading the code you can clearly see that the string is now json (it can almost look like a type). Of course, if that function does anything else, then naming it `json` is wrong but the function is also breaking away from being pure and single-purpose.
Re: How to name things in programming
#80Earlier quoted context omitted.
int n = 42; int acc = 0; Fixed Edit: Install http://wbond.net/sublime_packages/alignment and add this key binding `{ "keys": ["ctrl+shift+a"], "command": "alignment" }`.
You will find, if you spend the effort to look, that different people process information completely differently. To someone who views this as a table, the above is so much more readable that it doesn't even bear thinking about. To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop. What the hell are you doing with n? Oh, if I look far enough, there is…
Madonna, Rain, 3:45
Lady Gaga, Bad Romance, 4:17
U2, In God's Country, 3:57
LCD Soundsystem, I Can Change, 6:31
vs Madonna Rain 3:45
Lady Gaga Bad Romance 4:17
U2 In God's Country 3:57
LCD Soundsystem I Can Change 6:31
I'm not questioning that you find columnized code hard to read I'm just wondering would that apply to all forms of info? Your email list with time, name, subject. Your bank statement with data, biller, amount?If not any idea why tables work for you sometimes and not others?