Don't commit when you're drunk | Hacker News Reader

Don't commit when you're drunk

github.com

89 pointsonatm73 comments

This is wrong, this goes against DVCS philosophy.

You should be able to commit all you want all night long, but should not be able to push.

Precisely! And that's why we have two (logical) levels of commit.

Pushing drunk is fine. It's writing the code drunk which isn't.

I've written and committed my best bugs when drunk. Undoing them was a valuable learning exercie. The finest being, in C:

   if (nr = 0x56) ...

That took and entire day to find and made me religiously avoid lvalue assigments in expressions by doing:

   if (0x56 == nr) ...

I've written both my greatest (and most ingenious) code, and my absolute worst code while drunk. It seems to send me to one or the other extreme. No "average" drunk code here! Just awesome problem solving, or terrible terrible bugs!

I'm sure everyone's seen this a thousand times by now, but it's incredibly pertinent for your comment: http://xkcd.com/323/

That should generate a compiler warning. And if you're not a criminal you have warnings set as errors.

This was an oooold SunOS compiler that didn't warn about much other than you owe Sun more cash.

Also when you're drunk, the warnings result in "ahh who cares" :)

There is nothing incorrect or dubious in C about an expression like if (foo = bar), so it wasn't considered a reason to warn the user about for a long time, despite being a rather common culprit for bugs. Compilers popping up warnings about that is a fairly recent event.

Pretty sure that's been a warning for a long long time in most compilers. They require you to wrap the assignment to suppress it, that is: if ( (foo=bar) )

Anyho, it really depends on what your -W level is set to. It's good practice to use "-Wall"

-Wall doesn't give all errors though, you probably want -Wall -Wextra.

What a misleading name for a compiler flag.

Yes this is why people worship LLVM...

That's still stupid. Put the assignment on its own line.

Wow, what an insightful comment.

Likewise.

I hope you're being sarcastic!

Under what circumstances would you place an assignment into an if statement condition?

I like doing it in certain cases. It definitely helps in a while loop when you are working with a stream, iterator, or stack and pulling items off while it isn't empty. Not really sure about the if, it's just kind of convenient sometimes. Guess it all comes down to preference. Too much use and it becomes very unreadable.

You just gave me an example of a loop. In what circumstances do you find it convenient, and when do you feel that the advantages of convenience outweigh that of code readability?

If it's a single assignment, then it's merely a preference. I cannot think of a case where it is explicitly better for a single conditional.

However, a compound conditional can actually be more clear if the assignment is there in many cases. For example:

    if ( (elt = db.getNextResult) && elt.shouldProcess){
        ...  ...
    }

In a compound conditional, the assignment is forced to be wrapped in parenthesis, so the ambiguity doesn't exist.

Anyho, that's that.

With that if statement, does it first assign the value of db.getNextResult() and then check the elt.shouldProcess variable to see if it is true or false, or does it firstly check to see if elt.shouldProcess is true or false and then load the next result from the database?

Conditionals are evaluated left to right chris. It's no different than any other conditional. An assignment simply evaluates to the lvalue.

According to C99, 6.5.16 clause 4, the order of evaluations on operands is undefined and if an attempt is made to modify or access the operand is after the next sequence point then the behavior is undefined.

Chris, && and || are short-circuited operators that create sequence points. They are exceptions to that rule.

except where noted [e.g. special rules for && and ||], the order of evaluation of operands of individual operators and subexpressions of individual expressions, and the order in which side effects take place, is Unspecified.

This is basic stuff Chris, let's not debate the obvious, this kind of code is all over the place in the Linux kernel.

I appreciate your candour. Can you point me to where this sort of thing is used in the Linux kernel? It looks like it is frowned on to me:

* http://linux-kernel.2935.n7.nabble.com/PATCH-drivers-net-ifb...

* http://linux-kernel.2935.n7.nabble.com/PATCH-1-4-silicom-che...

* http://linux-kernel.2935.n7.nabble.com/PATCH-0-4-Staging-sil...

Not to mention, checkpatch.pl checks for assignments in if statements:

http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.g...

I should point out that someone tried to add a backdoor into the Linux kernel source through the use of an assignment in an if statement in 2004. What are your thoughts on this?

https://freedom-to-tinker.com/blog/felten/the-linux-backdoor...

Also, where is the place in the C99 standard that details the exception? Genuinely curious. When I reviewed the standard, all that is said about the if statement is in section 6.8.4.1, and that says nothing about short circuited logic, certainly nothing about "exceptions to the rule". This seems compiler specific, but I'm happy to be shown to be wrong - if you can point me to the part in the standard.

Sure, if by "fairly recent" you mean at least more than twenty years ago:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=1853

That's GCC. Some of us were blessed with commercial compilers.

GCC isn't the only compiler on the planet :-). Other compilers either started doing it more recently, or not at all. The construct it most often warns about is fairly idiomatic on Unix platforms, but not everywhere, so a lot of vendors were not quite as bothered about it.

GCC is indeed not the only compiler around, which is why I said "at least" :-) Even if you're stuck with some other compiler for production builds, it's handy to be compiling regularly with a variety of compilers so as to benefit from the union of the diagnostic abilities of all of them.

The construct is a useful idiom, but oftentimes there would be or ought to be a local coding standard recommending that you make what you're doing explicit by comparing the assignment result to the appropriate flavour of zero:

  if ((foo = bar) != NULL)

Now everybody can see what's going on, the warning doesn't arise, and no pedants can complain about the theoretically-unnecesary parentheses in `if ((foo = bar))`.

> GCC is indeed not the only compiler around, which is why I said "at least" :-) Even if you're stuck with some other compiler for production builds, it's handy to be compiling regularly with a variety of compilers so as to benefit from the union of the diagnostic abilities of all of them.

In my case, at least one of the compilers in question was for the 8051, the platform that won't fucking die. Due to the peculiarities of the aforementioned piece of silicon crap, the compiler was not entirely ANSI-compliant (various #pragmas were actually required to produce working code, indicating various parameters related to memory organisation and the such), thus making it rather difficult to compile the codebase with anything but that particular compiler.

> The construct is a useful idiom, but oftentimes there would be or ought to be a local coding standard recommending that you make what you're doing explicit by comparing the assignment result to the appropriate flavour of zero

This is the solution I adhere to as well.

Yoda assertions, nice.[0]

[0] http://www.codinghorror.com/blog/2012/07/new-programming-jar...

conditions* ;-)

Ha, yeah that's what I meant. Love seeing them described that way!

I hate this convention to put literals on the left hand side of the comparison. Every time I stumble upon code like this my brains stalls for an instant trying to make sense of the expression. It just looks ugly and wrong in my opinion.

It's also mostly useless because your compiler should warn you about your first construct (and tell you to add a layer of parens if that's what you really want to do).

I realize I'm being a bit irrational with this whole thing but for some reason code like this drives me nuts (that and people not putting space around arithmetical operators and such: int a=2*4+foo(1,2,3)).

I do a ton of code reviews, often as part of an interview process, less often, for embedded developers. Conditionals written with literal lvalues is something of which I tend to take note. You're right, it's not natural, and it's less readable, but there's usually a reason why people do it: experience. If you often work in weakly typed languages, or those which allow for weird coercion in conditional statements, it's sadly often easier to form a habit which guarantees fewer bugs than it is to say "I'll always type the boolean equality/strict equality operator."

"But why don't you use better languages, then?" Because in many cases (low-level resource-constrained systems programming), it's much, much easier to deal with these weird gotchas than to attempt to get exotic [1] languages such as Python, Ruby, Java, and sometimes even C++ (heap? who needs a heap??), to work. Even in cases where you're able to get these languages to work easily, you're just forcing yourself to become intimately familiar with the internals of some language with which you'll ultimately wind up wrestling [2]. Normally the point of such languages is to abstract away the system. This is the exact opposite of what you need in these environments.

"But it annoys me when people use literal lvalues where they don't need to." Ah, but this is the rub of forming a habit.

1: I'm mostly sarcastic in my use of the word "exotic" here. Don't go crazy, now. ;-)

2: Though to totally contradict myself, I will say that both Rust and Go look very, very interesting here.

I still hate yoda-conditionals, but after reading your comment I now realize they have value.

It's better to have slightly ugly if statements than to have silently broken if statements.

Slightly drunk is fine, for me it helps for not overengineering things and i just write code that works.

When completely sober, i think to much and i overengineer (overthink) stuff... Programming is just slower...

(Think DDD-like programming)

1 beer is enough to get very concentrated... Just don't overdue it (and don't make a habbit of it).

I only do it when i need to get things done, when time is limited... Never had serious bugs (Windows ME like) though :-P

It happens once in the 2 months and mostly it's for 2-3 days in the weekend (non-stop), with some light kind of music (Enya or concentration like mp3's) and headphones.

Yeah, i'm a nerd then :P

Why is this stupid frat house bullshit on the front page of Hacker News? We can do better than this.

Because someone coded it up, which is more effective than I was on my projects this weekend.

It boggles my mind that this needs to be said, even if in jest. Just looking at the subject, I think, "What kind of idiot needs to be told not to commit when drunk? Do they need to be told not to drive when drunk too?" And the article is worse than the subject.

You're right, it doesn't need to be said. Everyone knows you don't drive or commit when drunk. The problem is that "drunk you" might disagree with "sober you", and want to drive/commit anyway.

That's why you install this cool thingy that doesn't let you commit when drunk. Sadly, it's not as easy with cars and drunk drivers...

I believe that folks are actually starting to look into this. http://www.nissan-global.com/EN/TECHNOLOGY/OVERVIEW/dpcc.htm...

Have you considered the possibility that you have encountered something called a "joke"?

They can be a little tricky, but I'm sure you'll get the hang of them if you try.

Especially tricky before my first cup of coffee in the morning. Just ask my wife! :-)

What's wrong with a little bit of humor?

I felt the same way, and then I noticed that the authors included a Ballmer Mode.

Also, I learned that someone's made a breathalyzer attachment for the Arduino (should have been obvious, in retrospect). YMMV, but it was a good use of my 60 seconds.

stupid frat house bullshit

Why is this hatred and stereotyping in the comments of a front page Hacker News article?

Is it particularly uncommon for someone that both drinks and is passionate about programming to write code drunk? Someone incorporated an arduino breathalyzer into a source control tool with some jokey features.

What's so stupid or frathouse-ish about that? It's not super-duper strait laced and serious, but neither is life.

If you want to get drunk and write code that's great. Good for you. But for a bunch of HN users to vote that up to the front page and be super excited about it is dumb. It's the acceptance and promotion of immature "brogrammer" culture that I find really distasteful.

So you're dismissing a project because you drew an association between it and a boogieman caricature of people that you (perhaps even rightly so) don't like? OK, be my guest, but keep in mind that's a dangerous road to head down.

Obligatory xkcd ("Ballmer Peak"): http://xkcd.com/323/

Don't worry, it is already a supported mode, which only lets you commit between 0.13% and 0.15% BAC.

Yes, I realize (hope) this is a joke, but this is the most "programmer" response to a drinking problem I've ever seen.

    I know, I'll externalize and automate my impulse control!

    > Don't commit when you're drunk

That's a valid premise for whatever you do in life, not only Git.

It might be neat to replace the arduino/breathalyzer part with some sort of typos/minute metric, collected from the number of miss-typed commands you have had recently.

Trying to run `git psuh` too many times in an hour could get you a cooldown period so you can either sober up or wake up.

It should be fine to commit when drunk, that's what VCS is for. Make it tag the last sober commit and disable "git push -f" instead.

And it goes beyond being drunk: sometimes I code when I'm tired but can't sleep. I have a vcs to ensure I don't trash something irretrievably; also tests and ideally a decent type system to increase the chances my code does what it should.

Also, don't edit your bash profile when drunk! In my youth I did this and it took 3 weeks to return to normality - I didn't know about source code control in those days.

What about a check for prescription pain killers or amphetamines? Oh wait, those are culturally acceptable mind altering things. I'm half joking but this is a neat hack, although I know many functioning alcoholics that would laugh at the concept of this.

One of my old colleagues had the bright idea to log onto one of our production systems to "re-index some of the database tables" after coming home one Easter eve.

And yes, he wasn't directly sober at the time.

I was moderately amused when I got woken up about 3 AM and got to spend a few hours trying to revert the "re-indexing" ...

I think integration with ssh-key management to prevent people logging onto production systems when drunk would be a good idea for this project, don't be surprised if there is a pull request from me in the future ...

If you do, you better call Saul.

I'd think the best use of this interface would be to only allow you to commit while in the Ballmer Peak.

Gotta love the names..Krunk mode and Balmer mode. Who woulda thunk of that..oh no one except a drunkard. :-)

Kids and drunks always commit the truth.

I didn't even read this. Is it as dumb as I immediately assumed?

Is committing tired more dangerous than committing tipsy?

Don't get into any commitment when you are drunk.

Period.

definitely shouldn't commit with a decreased libido

Should be used in cars.

I've read about it being in some car(s) maybe a decade ago. Haven't heard about it since. Probably not something users want.

I'm pretty sure it's common to install a breathalyzer in cars nowadays if you've been caught with driving under the influence (probably repeatedly or over a certain percentage) in various countries / states.

They are -- I know a couple people that have had them installed.

Reply on news.ycombinator.com