
Everyone can write bad code - axiom92
http://madaan.github.io/wbc/
======
hawktheslayer
This point is particularly salient: _" Either Comment Nowhere, or Comment
Everywhere_". It reminds me of people who highlight so much of the textbook
that the unhighlighted words actually stand out.

~~~
maxxxxx
I always appreciate the line "//Incrementing i by 1"

~~~
sodapopcan
Just to add my own, I had a coworker who used to do:

# Set x to 1

x = 1

...not even kidding.

~~~
maxxxxx
You could probably automate this and write a plug-in that that translates
every line of code into plain English :)

------
lifeisstillgood
I am getting a bit annoyed by holier than thou coding evangelists.

Writing good code is hard,

writing good tests is hard,

writing good docs is hard,

and even harder is writing code to do the _right thing_.

If someone has lots of exploratory code, trying out different approaches to a
problem, maybe producing some performance comparisons, maybe exploring that
weird API the other part of the company is offering, these are all valid
reasons to not follow a prescriptive methodology.

Yes, having short iterations with working software as _a_ deliverable is
great.

Having close contact with your user base for fast feedback is great.

Having continuous integration so that at almost any point we can see genuinely
where we are is great.

But honestly, after those three, which I think compare to "use memory managed
languages" in the list of genuinely useful software engineering innovations
(and let's face it, none of them are software but _process_ , and they are all
arguably the same thing - fast feedback loops) I struggle with the religious
zeal for pair programming or other "must haves".

it's not they aren't sensible practises, but with a gun to your head, you need
to carefully choose what to throw away.

Trying to simplify my argument:

There are no silver bullets left in the software pistol. we can make our code
as sweet as we like but the _value_ will come from building the right thing,
not building the wrong thing in the right way.

~~~
artimaeis
> Writing good code is hard

So just strive to write code that _just_ accomplishes your objective.

> writing good tests is hard

So just write tests that are good enough to cover the code you've written.

> writing good docs is hard

So just write docs that are good enough to explain what's necessary to the
audience for the doc.

I personally don't see the linked article as evangelical - but maybe that's
because I'm brainwashed by the message it. But to me a 16 point list doesn't
read at all like a silver bullet.

------
bastijn
“If your method is less than 100 LoC you have to combine them”.

“Classes less than 9000 LoC have to be combined and do not deserve their own
file.”

“Method documentation is just because it is required. Contents can be just the
method name.”

“Code reuse is king. If you need different functionality but share at least a
field just override all methods and do not call base.”

“Just access the resources you need but don’t bother deaccessing, someone else
can do that for you.”

“Method names are worthless, their IDE will suggest them anyway.”

“If you need new functionality but do not want to break the old just add
another field and an if statement to enter a new code path.”

\ _\_ cheesy US presenter voice \ _\_ Today! in another episode of code
reviews at the office!!

Disclaimer: love my job and my colleagues :)

~~~
fhood
> “If you need new functionality but do not want to break the old just add
> another field and an of statement to enter a new code path.”

Oof.

    
    
        def a(b, c, d, e=None):
            if e:
    

is way more common in my code than it should be.

~~~
bastijn
Exactly. It’s a competition to beat the previous editor’s cyclomatic
complexity score! In fact, I should have said:

“If you refactor a method without increasing its cyclomatic complexity don’t
bother sending for review.”

~~~
AstralStorm
Uh? Every code should be reviewed. Decreasing complexity can cause inadvertent
bugs, including ones not caught by regression tests.

Unless this was cheeky sarcasm in which case you shouldn't replace the
previous point just add this one.

~~~
bastijn
I think all the points in this thread are (cheeky) sarcasm :).

------
fhood
I'm feeling attacked by this article on a personal level after reading #6

~~~
lostcolony
I think it means production-y code. Exploratory code, ideation, POC, etc? All
valuable. Code you expect to throw away, basically.

~~~
dvlsg
Until the code you expect to throw away turns into production code forever,
anyways.

~~~
fhood
I always go in with good intentions, but then the code is already written, and
it works, and re writing it would be boring...

Edit: Now that I think about it, it isn't the re-writing I mind so much, it is
the prospect of re-debugging

------
wpasc
Write as much code as you can in as few files and methods as possible

~~~
pavel_lishin
Everything is either a giant function, or every possible line that can be
split out, is.

~~~
jandrese
Every line is its own factory in its own class split across three different
files. There are so many layers of abstraction that your codebase looks like a
hall of mirrors.

------
ancarda
Am I right in thinking #5 is asking for premature optimization? I thought that
was generally discouraged

~~~
maxxxxx
The premature optimization thing is often used as an excuse to write plainly
stupid code without any thought. I think that's what #5 is about.

~~~
kragen
Several times I've heard novice programmers cite the "premature optimization"
saw as an argument against doing things that weren't optimization at all.
Handling edge cases correctly, for example, or throwing exceptions instead of
returning incorrect results, or handling two input formats instead of one, or
tolerating trailing whitespace on input.

"Optimization" means "making code run faster without changing what it does".
If you're changing the code's behavior in an observable way, that's not
optimization.

~~~
maxxxxx
Also things like copying huge arrays back and forth or hammering the database
repeatedly.

------
pavel_lishin
Don't forget #17: Work in isolation so nobody bothers you.

~~~
sodapopcan
You mean #10 _glasses emoji_

------
dentemple
Everyone writes bad code except me.

------
jacinabox
Here I am thinking that they would really expand on the points but no, it's
just a list.

~~~
combatentropy
That's HN's job.

------
hawktheslayer
I love that there are 16 points listed out using hexidecimal

------
baby_wipe
I know it is meant to be satirical, but the reality is there are trade-offs
involved with each of these points. I don't think it is wise to treat any of
them as absolute rules.

Maybe someone smarter than me could write about the trade-offs involved with
each and when to break the rules.

------
strkek
Reminds me of _How to write unmaintainable code_ [1].

[1] [https://github.com/Droogans/unmaintainable-
code](https://github.com/Droogans/unmaintainable-code)

------
sodapopcan
Look at the data??? Why would I do that?? While the feature I'm building isn't
useful to me, I know exactly how I would use it if it was, so that's exactly
how all my users are going to use it. Duh!

------
ppeetteerr
"Never consider the product when writing code. Product should adapt to code,
not the other way around"

------
HumanDrivenDev
Everyone can write bad articles

\- click-bait title

\- authoritative tone

\- devoid of insights or new information

\- arguments that are either badly argued or blindingly obvious

