Live data from Hacker News

How to name things in programming

slideshare.net

151–160 of 177 posts

Re: How to name things in programming

#151
post #143

Earlier quoted context omitted.

pairwise . reverse . map (+1) . flatten . replicate 2 . map (*3) $ input With all the functions being pretty standard (pairwise is my own name for subdivideListEtc, but it seems like a terse name that still explains what the operation is). Every fragment in this composition is smaller than the names you supplied, and all but one of them are standard Prelude functions that should be considered basic knowledge in Haske…

More elegant, more concise but less understandable. This is subjective but I would argue it's harder to get a higher level understanding of what your code is doing versus what mine is. Also, honestly, nobody will know what "pairwise" is without looking at the definition; I mean the name is appropriate and elegant, but that doesn't mean it's clear. Here's another perspective: My code, despite having several complicate…

Assuming basic knowledge of Haskell, there's not much between them (one function definition that takes all of two lines).

Both of them clearly show what the function is doing in an operational sense, but neither give any high-level indication of what the whole thing is for. They don't say whether this is part of the computation of a hash function, or a format conversion, or what have you -- that takes documentation and proper naming. These just tell you a way of turning one random list into another.

Re: How to name things in programming

#152
post #14

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

In the past I've wanted a tool like that, but now I've come around to the idea that I want an editor that will display the code the way I'm used to however it's formatted. Lining up the equals signs would be a good candidate for an display formatting plugin. One the other hand when I've raised that idea with programmer friends of mine you can see the hair stand up on the back of their necks. People seem to really hate the idea that the editor might show you seaMonkey(do) instead of sea_monkey(do)

Re: How to name things in programming

#153

Earlier quoted context omitted.

Functional programming languages use single-letter parameter names as a tool to help condense functions and allow easy parsing. This is largely due to their desire to emulate mathematical formulae. 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 descri…

Actual mathematical functions have some of the most useless, non-descriptive or vaguely metaphorical names going, so I'm not sure promoting an isomorophism with FP is a good thing. Examples: "bessel", "spherical_harmonic", "delta", "zeta"... Math is hard, and the terseness of mathematical notational conventions is one of the things that makes it so. Names that carry meaning with them are an aid to the naive user, and…

> Secondly, naming a function "json" requires the user read the code or the comments to figure out what it does, and blocks the user of the name for anything else that returns json. Suppose rather than a string you have a list that you need translated to json... what do you name the function?

This is exactly what functional programming seeks to solve. This should be the same function. Every language that has the power to do FP has the ability to do multi-functions or pattern matching just for this kind of situation.

Re: How to name things in programming

#154

What did he mean by "never use passive when you can use the active (respect grammatical rules for identifiers)", on the slide 15?

passive: He was told by a doctor to take a pill active: The doctor told him to take a pill

He provides examples `class PlanEvents`, `class EventPlanner`, `class Scheduler`. To me, they all seem to be active. Any thoughts?

Re: How to name things in programming

#155

Earlier quoted context omitted.

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

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

I write a lot of coffeescript ;-)

Joking aside, on my current project we elide the parentheses when making function calls with arguments. So:

    myfunc(foo)

    myfunc (foo) ->
is an important difference when I'm reading the code. If you write:

    myfunc       (foo) ->
it means the same thing, but it completely throws me for a loop because I have to look ahead too far. So you are right, I don't look at it the way the interpreter does. I'm inferior and can only handle a grammar with a single look ahead ;-)

Re: How to name things in programming

#156
post #137

This is a timely article because I was just talking to a friend of mine that works at Google and is about to start an internal project that will be written in Go. I told him I'm not sure I'd ever fit into the Go community because the Go community seems to like variable names that are extremely short. For example: func (h Handler) ServeHTTP(w http.ResponseWriter, r *http.Request) I've even been "gently corrected" in #…

The thing about the arguments to an http.HandlerFunc is that everyone uses w and r for the argument names because everyone else does. Additionally, if you're writing a http.HandlerFunc, you're likely repeatedly exposed to a bunch of other http.HandlerFuncs in standard library code and gorilla/mux, all of which use w and r.

Because of this, anyone who's been wrangling HandlerFuncs for more than a few days tends to converge on w and r. At this point it's no more a problem than using short variables like d for distance or r for radius in math formulas.

As an aside, I have a file open right now with a struct member called "TentativeSpacesPerIndent int"; I'm not worried — yet — about how ungainly long it is because I'm still trying to figure out what indices I need to keep track of, and the last thing I want to do is confuse myself into using one type of index when I need another, or perhaps I need to track of something else entirely. On the other hand, I have

  func NewScanner(bs []byte) Scanner
and all the thought I put into the name of the argument is "if a single byte should be a 'b', what should a slice of bytes be? 'bs'." That seems to be sufficient length for a five-line function.

Re: How to name things in programming

#157

Earlier quoted context omitted.

passive: He was told by a doctor to take a pill active: The doctor told him to take a pill

He provides examples `class PlanEvents`, `class EventPlanner`, `class Scheduler`. To me, they all seem to be active. Any thoughts?

I also found the examples confusing. What I got is they are all nouns (respect the grammar rule of having nouns for class names) but `PlanEvents` reads like data that is going to be processed (passive) whereas `EventPlanner` and `Scheduler` are concepts that process data (active). They have a verb: "plan" and "schedule".

Re: How to name things in programming

#158

Earlier quoted context omitted.

He provides examples `class PlanEvents`, `class EventPlanner`, `class Scheduler`. To me, they all seem to be active. Any thoughts?

I also found the examples confusing. What I got is they are all nouns (respect the grammar rule of having nouns for class names) but `PlanEvents` reads like data that is going to be processed (passive) whereas `EventPlanner` and `Scheduler` are concepts that process data (active). They have a verb: "plan" and "schedule".

Thanks for clarification. I think I disagree with the author here. In my experiences, it's sometimes awkward to use '-er,' '-or' suffixes to turn name into concepts that process data (active) e.g. JobUpserter, ...

Re: How to name things in programming

#159

Earlier quoted context omitted.

Convention. FYI for non-Pythonistas: the prevailing convention is lowercase_with_underscores for everything, except CamelCase for class names. Of course, the core types are mostly lowercase. I think it's somewhat like being a famous scientist; you know you're really important if your name is lowercase.

This is similar to most dynamic/scripting languages of that era, for that matter; both Perl and Ruby (and, IIRC, PHP) have similar conventions. Things got bungled when Java programmers started insisting on camelCased function names even outside of Java.

Things got bungled when Smalltalk used an old version of ASCII which had a backarrow instead of underscore. Smalltalk used backarrow for assignment and had no way to separate words in identifiers other than CamelCase. Smalltalk programmers kept this convention when they moved to Java, even though the technical limitation was gone and they could have used a more legible style.

Re: How to name things in programming

#160
post #124
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…

Your argument is not an argument against comments, it's against any kind of description. Your code works just as well if you assigned each function a unique number starting from 'func0' - that's how code obfuscators or minifiers work. Unless the act of shoving comments into function names makes the compiler type-check them, you are still writing something that the compiler will ignore eventually.

I think his argument is: "Comments is not a substitute for short functions and javadoc". That sounds extremely valid, imho.
Post reply on HN