Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to name things in programming

slideshare.net

Post reply on HN
Print view View original

91–100 of 177 posts

Re: How to name things in programming

#91

Post by falcolas »

cessor wrote: post #63

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

> Why would you write something that the compiler will ignore eventually?

Because your real target for your code is not the compiler, it's your co-workers, who will have to go back and read and modify your code. Plus, they may not be able to contact you with questions about your code.

A single well written comment can save your co-workers from having to read a hundred lines of test code (and correspondingly, test code boilerplate). Why not give them that kindness?

> Comments are either obvious or they're lying.

This argument only applies to poor comments, which were not maintained alongside the code. If you just remember that the audience your code was written for is not the compiler, it makes more sense.

Re: How to name things in programming

#92

Post by userbinator »

greggman wrote: post #80
mikekchar wrote: post #73

Earlier quoted context omitted.

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…

I'm curious, would you prefer your favorite music player list things like this 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? Y…

I'm not the parent, but as someone who also doesn't prefer aligning variable initialisers I can say the reason is that declaring variables and initialising them is not something I see as being tabular --- they're just a sequence of statements, and I wouldn't align them just like I wouldn't do this with a series of function calls:

    foo        (5, 7);
    barbar        (j);
    do_stuff(6, 1, 7);
or this with flow control statements:

    if   (x == y) {
      ...
    }
    for  (...) {
      ...
    }
    while(...) {
      ...
    }
Things like array initialisers, however, I do align.

    int n[16] = {
      15, 17, 22, 38,203,155,  7, 10,
     255, 11, 44,  1,  0,  0,  5,227
    };
To someone who reads code the way a computer parses it (as I do), the added space can completely throw them for a loop.

Actually, if you were really reading "the way a computer parses it", you'd ignore whitespace completely.

Re: How to name things in programming

#93

Post by crimsonalucard »

Grue3 wrote: post #61
crimsonalucard wrote: post #4

When structuring code, elegance and efficiency always take top priority. However, when naming, my philosophy is always clarity over elegance. for example (in python): def reverseListAndAddOneToEachElement(input_list): Ugly, but clear. I don't even need to write out the full definition you already know exactly what it does.

CamelCase for functions in Python? Why.

why not?

Re: How to name things in programming

#94

Post by mercurial »

wetmore wrote: post #86
SamReidHughes wrote: post #43

Earlier quoted context omitted.

> To be honest it actually makes code cleaner and therefore easier to read. It does not logically follow from the code being "cleaner" that it is easier to read. Having to scan across a field of whitespace to get to the number makes it harder to read and easier to make mistakes. Having the indentation of the number be unrelated to the length of the variable name adds another aspect that makes it harder to read and ea…

It depends on context. For example, here is a function from a project I'm working on: parseModifier : String -> Outcome Modifier parseModifier s = case s of "shift" -> Ok Shift "ctrl" -> Ok Ctrl "alt" -> Ok Alt "meta" -> Ok Meta "command" -> Ok Meta "windows" -> Ok Meta x -> Err I find it easier to read as is rather than if I dropped the alignment: parseModifier : String -> Outcome Modifier parseModifier s = case s o…

I agree that unaligned switches/pattern matches are bad (and in fact, there is an utility for OCaml which will nicely indent your pattern matches).

Re: How to name things in programming

#95

Post by crimsonalucard »

walshemj wrote: post #67
tmikaeld wrote: post #7

Earlier quoted context omitted.

I like the logic of this, but it goes against all books that i've read to keep it short. Why do we need to keep it short?

Easier to keep short names in programmers memory and less chance of spelling mistakes.

in my case spelling mistakes are handled by the the editor or IDE.

Re: How to name things in programming

#96

Post by sbov »

crimsonalucard wrote: post #4

When structuring code, elegance and efficiency always take top priority. However, when naming, my philosophy is always clarity over elegance. for example (in python): def reverseListAndAddOneToEachElement(input_list): Ugly, but clear. I don't even need to write out the full definition you already know exactly what it does.

If you feel the need to write a reverseListAndAddOneToEachElement function for your code base, it is probably because you have lots of instances of it.

If you have lots of instances of it, its probably because there is a higher level, domain related reason why you're doing it. Your function should be called that, not reverseListAndAddOneToEachElement.

Re: How to name things in programming

#97

Post by bshimmin »

DougWebb wrote: post #89
bshimmin wrote: post #83

Earlier quoted context omitted.

What does "Make life of" mean? As a native English speaker, I don't understand it; I presume it means "Make life better for", though the closest we have in English is probably "Make light of", which means something completely different (and is slightly funny in this context).

He means "Make the life of people..." in each case. The phrasing without "the" sounds to me like Powerpoint-Speak... leaving out minor words in order to fit more bullets onto a slide. Those minor words are usually grammatically necessary, but in the context of a slide presentation the presenter's verbal part of the presentation clarifies ambiguities in the visual part.

Ah, thank you, you must be right. "Make life better for people..." would in each case have been grammatical and slightly more comprehensible to me!

Re: How to name things in programming

#98

Post by a3n »

ttty wrote: post #14
g1236627 wrote: post #12

I 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" }`.

I think both practices are pathological. The GP is restricting all variable names to an arbitrary length that will likely obscure meaning. The parent is arbitrarily determining line length based on whichever variable is longer; he may also be mixing in the GP's arbitrary var length rule in order to get a visually pleasing line in the local context.

Prose is obviously different, but it's probably worth considering that the only consideration for the length of a paragraph is the rules of paragraph writing, and not at all the physical length of words and sentences.

And then there's refactoring and renaming, and what that does to your artfully placed characters.

Figure out your placement and spacing rules (or better, use a canned set of rules), use them, and think about other things.

Re: How to name things in programming

#99

Post by seabee »

sbov wrote: post #96
crimsonalucard wrote: post #4

When structuring code, elegance and efficiency always take top priority. However, when naming, my philosophy is always clarity over elegance. for example (in python): def reverseListAndAddOneToEachElement(input_list): Ugly, but clear. I don't even need to write out the full definition you already know exactly what it does.

If you feel the need to write a reverseListAndAddOneToEachElement function for your code base, it is probably because you have lots of instances of it. If you have lots of instances of it, its probably because there is a higher level, domain related reason why you're doing it. Your function should be called that, not reverseListAndAddOneToEachElement.

IME this also happens not because the function is reused, but because the programmer is trying to create functions at a 'high level of abstraction'. Usually this means one function that has a bunch of descriptively-named function calls chained together to avoid needing more than one control structure, or to hide for loops in other functions.

Re: How to name things in programming

#100

Post by msellout »

techiferous wrote: post #84
msellout wrote: post #74

Earlier quoted context omitted.

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.

> The aspect of Ruby that frustrates me the most is over-use of anonymous blocks when a good name would help me enormously. Ruby gives you enough tools to write code clearly with good names if you want to. I think your complaint might be more about the particular style of Ruby a certain programmer wrote than the language itself.

Correct, though I find that a language is more about the community and culture than the syntax itself.
Post reply on HN