Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please do not attempt to simplify this code

github.com

Post reply on HN
Print view View original

181–190 of 327 posts

Re: Please do not attempt to simplify this code

#181

Post by kstrauser »

spacemadness wrote: post #132
mumblemumble wrote: post #115

Earlier quoted context omitted.

I wish code like this still felt normal to me, but over the past ~10 years it seems that many people have come to value brevity over explicitness. I strongly prefer the explicitness, at least for important code like this. More than once in my career I've encountered situations where I couldn't figure out if the current behavior of a piece of code was intentional or accidental because it involved logic that did things…

Every time some code reviewer comes into my PR and says something along the lines of "you know you can just write it this way" where "this way" means obfuscating the code because "clever" and "shorter," I die a little on the inside. This is from experienced devs who should know better. At one point I wrote a comment write above a section I knew would be targeted by this kind of thinking explaining it must be written…

I only recommend that if the more explicit code is less idiomatic. For example, if someone appends to a list in a Python loop where a list comprehension would express the same thing plainly, I’ll suggest it. That’s it.

Otherwise, please optimize for writing stuff I can understand at 2AM when things have broken.

Re: Please do not attempt to simplify this code

#182

Post by verandaguy »

Speaking specifically about cases where any not-completely-trivial `if` is matched with an explicit `else`: I wonder to what extent this code could be simplified if the authors of k8s had chosen to design around using structural pattern matching rather than `if`/`else` blocks?

Lots of mainstream languages with support for structural pattern matching have compile-time tooling to check whether a match was exhaustive, which alone could serve as an idiomatic solution while increasing information density in the code.

Re: Please do not attempt to simplify this code

#184

Post by readthenotes1 »

One part of what NASA did was have every line of code reviewed by many people, including someone whose sole job was to make sure the comments matched the code and vice versa.

If you do not take such care, excessively for both comments are inevitably going to drift from the code and lead to incredible confusion.

Re: Please do not attempt to simplify this code

#185

Post by al_borland »

wavemode wrote: post #98

Am I weird in feeling like the code in this file is really really... normal? Like, it's verbose in certain ways due to being written in Go, as well as due to not relying on any deep abstractions (and I don't mind this - abstractions are a double-edged sword), but in general, as code, it seems typical - and if the header text didn't exist I wouldn't think twice about the style it's written in. Maybe the disconnect her…

In most code I look at, to try and get clarity on something I’m trying to do, I have no idea what’s going on. Variables seem arbitrary, everything seems cryptic, and I can’t be bothered to try and track down what’s happening.

My own code doesn’t look like that at all. I have long descriptive variables, what I think are easy to read and follow functions, etc. Sometimes I think if I want to be “good” I need my stuff to look like what I find, but at the end of the day, I want it to be easy for me (and hopefully others) to maintain. If no one else can read my code, I don’t view it as job security, I view it has handcuffs.

Re: Please do not attempt to simplify this code

#186

Post by kazinator »

throwanem wrote: post #82
supportengineer wrote: post #47

Earlier quoted context omitted.

I went right into the code and looked for 'if' statements without 'else' statements. There are plenty. I don't see how you can have any exceptions to this rule if you are truly committed to capturing all branches.

If the 'if' condition matching always results in a thrown exception, a return, or likewise, then you don't really need an 'else' unless you're using a language which supports conditions and resumption (conformant Common Lisp implementations, and not really anything else I know of). The 'else', implicitly, is that the flow of control leaves the scope of the 'if' block at all. (I haven't read far enough into the code t…

"Else" is for when the if condition is false.

A resumable exception initiated in the "then" part of an if will not go to "else" when control resumes; it will go to the next statement after the if.

Re: Please do not attempt to simplify this code

#187

Post by jjnoakes »

marcus_holmes wrote: post #162
dskrvk wrote: post #137

Earlier quoted context omitted.

But comments go out of date, and the compiler doesn’t check them against the implementation. To document + enforce the intended functionality, use tests.

Comments (should) explain the "why" not the "what". The "why" doesn't go out of date, even if the "what" does.

The why can also go out of date. Maybe not as frequently? I don't have a great intuition for the ratio, but it is certainly more often than never.

Re: Please do not attempt to simplify this code

#188

Post by avs733 »

p-e-w wrote: post #178
senorrib wrote: post #121

Earlier quoted context omitted.

Oh, the Schrodinger's Bug.

Schrödinger's Hubris, actually. The claim that a codebase of 420k lines contains "only one error" is of course absurd, and the members of this forum would laugh anyone out of the room who made such a claim about any other project, pointing out how they cannot possibly know, actual logical contradictions in the claims as described by GP, or just plain ridiculing it without further elaboration. But since the code in qu…

maybe just labeling it journalistic license would be simpler and more accurate.

I doubt any of the people who actually write the code would stand by when that claim was made and not clarify it to 'we only found one bug'.

Re: Please do not attempt to simplify this code

#189

Post by adrianN »

odyssey7 wrote: post #154
CodeWriter23 wrote: post #100

Earlier quoted context omitted.

Regressions are not implied by that statement. A bug doesn’t exist in the human realm until a human observes it.

“Program testing can be used to create 1 the presence of bugs, but never to show their absence” 1) edited

That is wrong in general. With enough tests you absolutely can show the absence of bugs for certain programs. It is for example easy to test „hello world“ exhaustively.

Re: Please do not attempt to simplify this code

#190

Post by adrianN »

Alupis wrote: post #34
andix wrote: post #22

Earlier quoted context omitted.

The space shuttle became obsolete technology after all those years. Would've needed a redesign.

> The space shuttle became obsolete technology after all those years. Would've needed a redesign. Are people aware of how old the technology is that's currently putting objects and people into space? No, the space shuttle was not obsolete. It was expensive... very expensive. To this day, we still don't have a replacement for it's capabilities though.

What so bad about old technology? Siemens is still selling point mechanisms based on designs that are almost as old as electric motors themselves. They work just fine.
Post reply on HN