6 ms·
Everyone can write bad code
- dentemple 9y agoEveryone writes bad code except me.
- strkek 9y ago"Nobody actually creates perfect code the first time around, except me. But there's only one of me." -- Linus Torvalds https://www.youtube.com/watch?v=4XpnKHJAok8&t=1339s https://www.youtube.com/watch?v=4XpnKHJAok8&t=1339s
- fhood 9y agoI'm feeling attacked by this article on a personal level after reading #6
- lostcolony 9y agoI think it means production-y code. Exploratory code, ideation, POC, etc? All valuable. Code you expect to throw away, basically.
- dvlsg 9y agoUntil the code you expect to throw away turns into production code forever, anyways.
- fhood 9y agoI 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
- egeozcan 9y agoOh so this happens to other people too! I'm kind of relieved.
- lostcolony 9y agoThat requires managing expectations. Sometimes the way to do that is not tell anyone you have anything working, just "Yes, that should be possible".
- hawktheslayer 9y agoThis 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 9y agoI always appreciate the line "//Incrementing i by 1"
- artimaeis 9y agoOr the related "// going through each item (i) in the list (myList)" Yeah, it's a foreach loop. I remember my keywords.
- sodapopcan 9y agoJust to add my own, I had a coworker who used to do: # Set x to 1 x = 1 ...not even kidding.
- maxxxxx 9y agoYou could probably automate this and write a plug-in that that translates every line of code into plain English :)
- hawktheslayer 9y agoI've been working on old SQL code written 10 years ago, and the original developer used comments as a way to track his to do list (e.g. --TO DO: fix this procedure). It's safe to say that stuff isn't going to get done.
- slezakattack 9y agoOr comments written in the first person. "// We need to increment i by 1"
- egeozcan 9y agoThat is more like a paper version of the "I select text when I'm reading it" behavior rather than a way to signify importance. I know some people who rage-close websites if they can't select text.
- hawktheslayer 9y agoI love that there are 16 points listed out using hexidecimal
- wpasc 9y agoWrite as much code as you can in as few files and methods as possible
- pavel_lishin 9y agoEverything is either a giant function, or every possible line that can be split out, is.
- jandrese 9y agoEvery 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.
- justjash 9y agoIf a 1000 line method won't work, make it a 2000 line method.
- egeozcan 9y agoEveryday CSS gains a new way to define layout. Use all of them, all the times.
- jandrese 9y agoOr you can be one of those guys who obsessively has to use every feature in C++, especially brand new ones that have shaky support across different compilers.
- nurettin 9y agoUsed to be that guy until I found the perfect techniques that only suit me and the perfect compiler that only ICEs on the most insane of codes.
- pavel_lishin 9y agoDon't forget #17: Work in isolation so nobody bothers you.
- sodapopcan 9y agoYou mean #10 glasses emoji
- sodapopcan 9y agoLook 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!
- ancarda 9y agoAm I right in thinking #5 is asking for premature optimization? I thought that was generally discouraged
- deleted 9y ago[deleted]
- quotheth 9y agoThe "premature optimization is the root of all evil" thing is totally blown out of proportion. I think what they're saying is don't use that quote as a reason to write garbage slow code.
- artimaeis 9y agoTo me #5 is talking about the myth that surrounds premature optimization. That is - this idea that thinking through data patterns (or other basic aspects of code) early on is a waste of time. It's usually not. Making the choice to work with collections that can be accessed in O(log n) rather than O(n^2) is a trivial optimization. Maybe you don't need to scope out every subroutine, but taking the time to review the basic performance features is something we can all strive to do.
- maxxxxx 9y agoThe 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 9y agoSeveral 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.
- jacinabox 9y agoHere I am thinking that they would really expand on the points but no, it's just a list.
- combatentropy 9y agoThat's HN's job.
- lifeisstillgood 9y agoI 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 9y ago> 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.
- sodapopcan 9y agoI agree with all of this, but none of the points in this post are evangelical, they are just things that should be always considered. You can then evangelize about how to achieve each point. You can follow every one of these (or rather, do the opposite of all of these) and still write awful code.
- HumanDrivenDev 9y agoEveryone can write bad articles - click-bait title - authoritative tone - devoid of insights or new information - arguments that are either badly argued or blindingly obvious
- bastijn 9y ago“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 9y ago> “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 9y agoExactly. 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 9y agoUh? 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 9y agoI think all the points in this thread are (cheeky) sarcasm :).
- ppeetteerr 9y ago"Never consider the product when writing code. Product should adapt to code, not the other way around"
- baby_wipe 9y agoI 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 9y agoReminds me of How to write unmaintainable code [1]. [1] https://github.com/Droogans/unmaintainable-code https://github.com/Droogans/unmaintainable-code