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

111–120 of 177 posts

Re: How to name things in programming

#111

Post by dllthomas »

slig wrote: post #106
jacquesm wrote: post #28

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

> I once worked for a game programming company. One of the programmers there would name all his functions and variables for fruit and vegetables. It was his way of ensuring job security. Guess who got saddled with untangling the salad when he left the company. Looks like that guy followed this guide http://mindprod.com/jgloss/unmainnaming.html

From your link: "If you call your variables a, b, c, then it will be impossible to search for instances of them using a simple text editor."

If you can't search for single-letter words in your "simple text editor", why are you using that simple text editor to code? In vi, at least, it's trivial: /\

Re: How to name things in programming

#112

Post by enraged_camel »

falcolas wrote: post #91
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 cod…

>>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.

Your co-workers and your future self. :)

Re: How to name things in programming

#113

Post by joesb »

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…

I try to use full word, except for loop variable.

Not every shorten the same word the same way, not even yourself next year.

Re: How to name things in programming

#114

Post by walshemj »

kabouseng wrote: post #29
rumcajz wrote: post #22

Nice write-up. But there's not a single slide about usability and how it affects naming. If your library exposes 'getCurrentRuntimeContext' which is going to be used in every other line of user's code, name it 'ctx'. It's ambiguous, but it saves the user 3 seconds per 2 lines of code. As for the readability, when the reader encounteres 'ctx' for the third time (at line 6 of the source file) they will already know wha…

I'm not so sure that is good advice, and I come from C programming so we love to do that. With autocompletion in most code editors saving the user typing time is not a valid argument anymore, and I would rather prefer comprehensible if slightly more verbose code than accronyms everywhere. What is obviously ctx -> getCurrentRuntimeContext for you is completely foreign to the next guy. And sometimes you don't spend a l…

You are assuming that every one can recall 25+ letter names - dyslectics have problems with this sort of short term memory.

Re: How to name things in programming

#115

Post by crimsonalucard »

walshemj wrote: post #105
crimsonalucard wrote: post #95

Earlier quoted context omitted.

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

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 use pycharm which not only checks for mistakes like these, but it highlights and automatically formats code to fit within PEP guidelines. The whole IDE actually attempts to fit your programming universe within the app, including debugging, and even connecting to a database.

It does come at a cost, however. Pycharm is heavy app and can be slow at times. It's also a complex tool to learn, but I wouldn't say it's more complex than learning vim or sublime.

Re: How to name things in programming

#116

Post by wmt »

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…

Comments are not to explain corner cases, but to explain why are you you doing what you are doing, what is your motivation. Why are you calling a system API with these strange parameters? Why do want to sort this table? Why are you lazy loading these data structures?

If a function fits into page, refactoring it into several tiny well named functions will give you an implementation where you can easily see what you are trying to do, but makes it difficult to see what you are actually doing, as you need to jump around between function implementations to read it. With a few good comments you'll get the best of both worlds, and you can now read both your implementation and your intentions with a single continous read.

Re: How to name things in programming

#117

Post by nandemo »

forrest92 wrote: post #62

This seems like its trying to force advice for one domain to another when its not appropriate. I disagree strongly with one or two of the rules. But an even bigger problem is that some (or even most) of the advice either has little value or doesn't really apply to programming. In english, shorter is better, but I'd much rather a longer class name that I can understand than one that's abbreviated to the point where I…

This. Some of the advice only works out of context, for example:

> What's an appointment_list? A calendar

No. Chances are that "appointment" is already a thing in your domain language -- the language you'd use to talk to your customers and stakeholders -- and so appointment_list is a much clearer name than calendar, as long as we make the reasonable assumption that it names a collection of appointments.

Re: How to name things in programming

#118

Post by itsybitsycoder »

jacquesm wrote: post #28

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

I didn't think it could get much worse than my former classmate, who would name all his pointer variables after famous ghosts (casper, bloody_mary, etc) because they "weren't real", but I think your greengrocer friend still wins...

Re: How to name things in programming

#119

Post by agumonkey »

msellout wrote: post #74
jacquesm wrote: post #28

An 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.

With the functional composition and currification, you can get point free programming (variable-less definitions). Some people don't like it, I personally find it appealing (I like APL and such). To quote prof. Dan Grossman, lambda p: p[1] === lambda p: p.__getitem__(1) which he calls an `unnecessary wrapping` of itemgetter(1). Similar to `return true if else false` which most people would find redundant.

Re: How to name things in programming

#120

Post by Retra »

jkire wrote: post #55
dkersten wrote: post #51

Slide 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.

There are things that operate like doors but are not actually doors. So when you are explaining how it works, you have ambiguity to resolve.
Post reply on HN