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

141–150 of 177 posts

Re: How to name things in programming

#141

Post by steveax »

jacquesm wrote: post #23
ttty wrote: post #14

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

That's actually right against the style guideline of many projects which tell you explicitly not to do this but to simply put the = sign and value right after the variable name and be done with it. Lining them up serves no purpose and does not in fact make the code easier to read.

And in fact if there are great differences in the length of the names it makes it harder to read as scanning across and maintaining the correct line becomes more difficult.

Re: How to name things in programming

#142

Post by ericssmith »

kabdib wrote: post #66

Nice article. I loved the hieroglyph page; I think that functional programming failed for years as an engineering discipline because of the culture of that style of code. My early days of OOP, I started keeping a thesaurus on my bookshelf at work. Probably went overboard on naming for a while, but reigned it in. (Every writer shudders at their first efforts. Hoo boy). We would also hold short discussions about names…

"I loved the hieroglyph page; I think that functional programming failed for years as an engineering discipline because of the culture of that style of code."

I don't quite follow your observation, but if you are suggesting that this function would be better with verbose, Englishy naming, I think you are mistaken. Quite the opposite, the parametrically is better illustrated with hieroglyphs.

Regarding failing "for years as an engineering discipline", are you suggesting that imperative programming was "successful" because of the reliance on using naming to communicate intent in the midst of rampant state mutation and unbridled complexity?

Re: How to name things in programming

#143

Post by pherq »

crimsonalucard wrote: post #107
Confusion wrote: post #19

Earlier quoted context omitted.

When a long name only reflects what the code technically does, then I don't think it adds much above just writing (map inc (reverse input_list)) given that the code is shorter than the name. It would be different if the function would be reusable, but in my experience that is rarely the case with such technical names. There would be added benefit to abstracting it into a separate method when the method name would exp…

That was just an example (I should have picked a better one). Usually, the definition won't be shorter than the name. Either way it takes a second longer to decipher the lisp then it does to read english. When composing many functions of similar complexity, it helps that the reader does not need to examine the definition of every single one. In this case, your given example would be significantly harder to understand…

   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 Haskell. In addition, since the standard functions have parameters passed as values (rather than being part of the name like multiplyAllElementsByThree), this approach is easier to tinker with if one value was wrong (1 change, rather than 3 (name of function at definition, at use, and value in function definition)).

Re: How to name things in programming

#144

Post by crimsonalucard »

gsg wrote: post #129
crimsonalucard wrote: post #109

Earlier quoted context omitted.

If I felt the the person reading the code needed to know... I'd go ahead and make that name even uglier.

That doesn't quite fit with "you already know exactly what it does" - you left out a detail. Whether it is reasonable to leave that out or not, the point is that it takes a lot of text to unambiguously cover every possible facet of meaning even for tiny, simple operations.

> That doesn't quite fit with "you already know exactly what it does" - you left out a detail.

My mistake. Take it from another perspective. The name is good because it lets you know every single detail about the function except for whether or not it mutates the list.

> Whether it is reasonable to leave that out or not, the point is that it takes a lot of text to unambiguously cover every possible facet of meaning even for tiny, simple operations.

Of course naming is limited, you can't describe an entire program with just names. I'm simply stating a convention: Clarity over elegance. I'd rather make the name as descriptive as possible over as elegant as possible. Perfect clarity and perfect elegance are rarely achievable.

So in short, if I see opportunities to increase clarity, I will do so at the cost of elegance, and I will only increase elegance if there is no sacrifice in clarity.

also:

   createReversedListWithOneAddedToEachElementFrom(input_list)

Re: How to name things in programming

#145

Post by crimsonalucard »

Confusion wrote: post #24
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?

We need to expend effort to keep names short, while it is easy to let them become long. 'Keep it short' is shorthand for 'do not forget to expend effort towards keeping names from becoming long'. It's easy to unthinkingly come up with 'company_people'. It takes effort to reduce it to 'employees'. It's actually not just 'short', but 'short and simple'.

I think it's the other way around. Programmers instinctively want to keep names elegant, similar to how they structure their code. IMO they actually have to kind of step out of their comfort zone if they want to write an ugly (but clear) name.

Re: How to name things in programming

#146

Post by [deleted] »

crimsonalucard wrote: post #115
walshemj wrote: post #105

Earlier quoted context omitted.

And how would an ide know that n0cars should be nocars

An editor probably not know this but an IDE would. The IDE actually partially understands your code. If your function definition was (in python): def nocars but you called the function with: n0cars() The ide would highlight n0cars because it could not find the definition. The IDE literally destroys the possibility of making trivial mistakes like this in a non-compiled language. Of course this depends on the ide. I us…

[deleted]

Re: How to name things in programming

#147

Post by crimsonalucard »

squidbidness wrote: post #20
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?

In this case it's a symptom of poor cohesion and separation of concerns. If you find you're having to give very long names for things, it's worth looking for a way to decompose it into separate things that each do one simple thing. Then more than likely writing the code that composes the separate objects with the right operations will be the perfect substitute for the long name, and it will also be easier to maintain…

Who says reverseListAndAddOneToEachElement isn't defined via the composition of smaller "separate things that each do one simple thing?" The naming convention still stands as it is not a "symptom of poor cohesion and separation of concerns."

Re: How to name things in programming

#148

Post by crimsonalucard »

pherq wrote: post #143
crimsonalucard wrote: post #107

Earlier quoted context omitted.

That was just an example (I should have picked a better one). Usually, the definition won't be shorter than the name. Either way it takes a second longer to decipher the lisp then it does to read english. When composing many functions of similar complexity, it helps that the reader does not need to examine the definition of every single one. In this case, your given example would be significantly harder to understand…

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 complicated procedures, had naming that was so utterly clear you were able to implement the entire thing based off of the naming alone. I didn't have to explain anything to you, I didn't have to write any comments, yet you understood it within a second after reading it. Could one say the same about your code?

Re: How to name things in programming

#149

Post by icebraining »

hollerith wrote: post #127
icebraining wrote: post #72

Earlier quoted context omitted.

It's shorter because with +1 you need to write the variable twice. That said, I do prefer Python's += operator over ++.

Someone reading your comment might be left with the false impression that C does not have the += operator.

Fair enough, I meant Python uses += in lieu of ++, since it doesn't have the latter.

Re: How to name things in programming

#150

Post by stinos »

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…

This for instace sort of agrees that just tests isn't good documentation http://programmers.stackexchange.com/questions/154615/are-un...
Post reply on HN