How to name things in programming • Hacker News Board

Re: How to name things in programming

#121

Post by [deleted] » Mon, May 25, 2015, 4:37 PM UTC

IanCal wrote: post #64

Kiro wrote: post #58

Earlier quoted context omitted.

What do you think is a better name? reverseListAndAddOneToEachElement is describing the function but I agree it feels ugly.

For this level of grouping, I'd probably prefer something related to the actual domain. def convertDF4ToMX6(data): # The MX6 format is read as a stack rather # than a queue, and requires data to be 1 # indexed rather than 0 indexed like DF4 # link_to_MX6 format spec 1.3.2 (v5) # link_to_DF6 format spec 1.2.0 (v1) Why are we reversing and adding one? What's the reason we need to do that so much that we're combining th…

[deleted]

Re: How to name things in programming

#122

Post by Retra » Mon, May 25, 2015, 4:39 PM UTC

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…

That's actual tabular data though. The variables `n` and `acc` are not the same type of thing; they don't belong in the same table. (Unless you were making a table called "local variables", but that is already obvious or redundant.)

Re: How to name things in programming

#123

Post by thesimpsons1022 » Mon, May 25, 2015, 4:40 PM UTC

enraged_camel wrote: post #112

falcolas wrote: post #91

Earlier quoted context omitted.

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

in rare cases: your customer

Re: How to name things in programming

#124

Post by seabee » Mon, May 25, 2015, 4:41 PM UTC

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…

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.

Re: How to name things in programming

#125

Post by Retra » Mon, May 25, 2015, 4:41 PM UTC

barrkel wrote: post #90

greggman wrote: post #80

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…

Tables require sequences of structurally isomorphic operations. Columnized code can work very well for matrix calculations, for example. But most code that has structural isomorphism should be replaced by a loop or a function composition; repeated structural isomorphism is a redundancy that can be eliminated. Aligning the initialization of a bunch of unrelated variables is a bit of a mixed case. Sequences of initiali…

To be fair, the readability problem can be solved like this:

    source      = 10;
    timeout     = 20;
    wait_count  = 30;
    ch          = 0;
    accumulator = 40;
    
    access_denied_retry_callback_list = [];

(Still, it's not tabular data, so it has no business being a table.)

Re: How to name things in programming

#126

Post by [deleted] » Mon, May 25, 2015, 4:44 PM UTC

icebraining wrote: post #72

jacquesm wrote: post #47

Earlier quoted context omitted.

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.

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

[deleted]

Re: How to name things in programming

#127

Post by hollerith » Mon, May 25, 2015, 4:46 PM UTC

icebraining wrote: post #72

jacquesm wrote: post #47

Earlier quoted context omitted.

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.

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.

Re: How to name things in programming

#128

Post by Retra » Mon, May 25, 2015, 4:47 PM UTC

walshemj wrote: post #114

kabouseng wrote: post #29

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…

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

That is a very weak argument. Is there anything that suggests letter count is a barrier to dyslexics, and not, say, word count or number of obscure abbreviations?

Re: How to name things in programming

#129

Post by gsg » Mon, May 25, 2015, 4:52 PM UTC

crimsonalucard wrote: post #109

gsg wrote: post #48

Earlier quoted context omitted.

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

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.

Re: How to name things in programming

#130

Post by plorkyeran » Mon, May 25, 2015, 5:00 PM UTC

nandemo wrote: post #117

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.

None of the examples of just using a single word seemed like improvements to me. appointment_list to calendar was by far the worst—calendar can mean a lot of things, and a list of appointments was not even the first thing that comes to mind for me—but in all of the cases the single word meant something significantly different than the thing it was replacing.