Live data from Hacker News

How to name things in programming

slideshare.net

41–50 of 177 posts

Re: How to name things in programming

#41
post #30

Earlier quoted context omitted.

Which, when you add a third variable "stuff", will require you to go back and add a space for both n and acc, pollutting both the diffs themselves (making reviews harder) and the git-blame (making pinpointing bugs harder).

There is a plugin in sublime text that I just select the lines and hit ctrl+shift+a and alignes everything in one hit.

That there is a plug-in that makes it easy does not make it right. If you're working just by yourself you can do whatever you want but teamwork takes a slightly different attitude when it comes to reformatting. It's all too easy to get into a whitespace war with someone else (and you'll both look so productive!). A good team member will change what is needed and will separate cosmetic changes and functional changes by placing them in different commits and will apply the style guide while doing so.

Tracking bugs through changesets is hard enough, no need to make it harder on purpose.

Re: How to name things in programming

#42
post #33

Earlier quoted context omitted.

Which, when you add a third variable "stuff", will require you to go back and add a space for both n and acc, pollutting both the diffs themselves (making reviews harder) and the git-blame (making pinpointing bugs harder).

git diff -w

Yes, git diff -w is possible but it is not (unfortunately) the default (though I can see good reasons why it isn't).

Also, note that you can do the same in github:

Append ?w=1 to the url for the diff viewer and you'll get the whitespace ignored version.

Re: How to name things in programming

#43
post #31

Earlier quoted context omitted.

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.

To be honest it actually makes code cleaner and therefore easier to read. It's like design have you heard about grid? this is the same thing. Your eyes have to flow the lines. If not everything seems a mess.

> 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 easier to make mistakes.

It's also harder to edit, which makes you do fewer edits that make the code materially better.

Re: How to name things in programming

#44
post #10

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.

I am suspicious of names containing "and". I agree about clarity over everything else, but then why even make a function if all it does is calling 2 functions in sequence, and you can't name it on higher level of abstraction? In this case wouldn't [x+1 for x in input_list.reversed()] be even clearer? True, functions allow you to change code in one place and affect many places (so they prevent "forgot to update one pl…

> but then why even make a function if all it does is calling 2 functions in sequence

How else would you execute the functions? What initiates them?

Re: How to name things in programming

#45

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.

Here is where "first write good code" applies, at the design level. This function is begging to be two separate, composable functions that each only do one thing. reverse(addToEach(input_list, 1))

But what calls "reverse(addToEach(input_list, 1))" if not another function?

Re: How to name things in programming

#46
I first realized how hard is naming when I programmed in Forth. Amusingly, Forth is sort of a point-free type of language - everything happens on the stacks and there's no such thing as local variables, so a good chunk of the 'naming problem' goes away - but trying to squeeze a functionality in one or two lines can be difficult. The reason for this constrain is that I programmed mainly with a "block editor", a limited kind of editor that only 16 lines of 64 characters at a time. This wasn't an artificial constrain because I was working on a fully self-hosted hobby system, which had no file support (the [floppy] disk space was presented as a series of 1K blocks = 2 sectors = 80x16 bytes) and "block editors" are the easiest thing to implement in this case.

Despite the point-free nature of Forth, there's still the problem of naming functions ("words" in Forth lingo) and global variables. Programming in Forth is an interesting exercise because you quickly see the relationship between how you factor your code and how you name your "words". You discover by yourself many of the rules in the slides. But I find this is really the case when one uses the 64x16 block editor I mentioned. Using standard files and editors removes a lot of the constrains, but they also allow more sloppy coding (which may be a good thing if you have something better to do; e.g. you just need to write a throwaway script to get the job done).

In my experience you can spend a lot of time (re)factoring and (re)naming things. Sometimes it's valuable because e.g. it helps you understanding the problem, and sometimes you are just bikeshedding yourself.

Re: How to name things in programming

#47
post #32

Earlier quoted context omitted.

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…

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

#48

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.

Does it mutate the list in place or return a new one?

Re: How to name things in programming

#49
post #34

Thanks for the thorough write-up Peter! This pack of slides addresses "naming things" to depth that it could have been a little book... I miss a few things though. 1. Short functions can use abbrevs; because I can keep track of them. 2. "text_correction_by_editor" might convey a lot more info then "edit"; especially in code where "edit" (and derivative) are heavily overloaded. For instance I can imagine "text_correct…

Java class names are like Haskell function types. In fact, there are libraries that can autogenerate implementations for database logic by the name of the interface and methods alone, much like you can guess what the function does just by the types it operates on.

Re: How to name things in programming

#50
post #10

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.

I am suspicious of names containing "and". I agree about clarity over everything else, but then why even make a function if all it does is calling 2 functions in sequence, and you can't name it on higher level of abstraction? In this case wouldn't [x+1 for x in input_list.reversed()] be even clearer? True, functions allow you to change code in one place and affect many places (so they prevent "forgot to update one pl…

Function composition is by far the better solution, it is future proof and requires less memorization.
Post reply on HN