5 ms·
Not disputing the code quality of either above project, but over valuing brevity / being concise is a common cause of problems. Specifically, people will often
by ebbv 10y ago
Not disputing the code quality of either above project, but over valuing brevity / being concise is a common cause of problems. Specifically, people will often sacrifice readability and robustness for brevity.
At this point in my career I don't really value being concise at all. Which is not to say you shouldn't ever think about "Can I write less code here?" but the goal there should be writing less code to make what you're writing more robust, more stable, more readable and not just shorter.
If there's one thing I could tell every programmer early in their career (including a younger me) it would be; nobody's going to be impressed with how clever you were when they're frustrated trying to understand what the heck is going on. Including you in 6 months.
- rdtsc 10y agoThere is a difference though when it is something custom and new (say if this code defined or parsed a new protocol) vs parsing an existing protocol. Notice https://tools.ietf.org/html/rfc791#section-3.1 https://tools.ietf.org/html/rfc791#section-3.1 section diagram. That code is basically an almost perfect translation of the RFC diagram, down to the bits involved. That is the beauty here: minimal impedance mismatch between the specification and code.
- Denzel 10y agoYou can eliminate the impedance mismatch entirely by using the specification as your code [1], as Alan Kay's Viewpoints research team did. ;) [1]: http://www.moserware.com/2008/04/towards-moores-law-software-part-3-of-3.html http://www.moserware.com/2008/04/towards-moores-law-software...
- rdtsc 10y agoHa! Interesting, just feed the diagram to the code.
- matt_wulfeck 10y agoIt's amazing that this is still highly debatable in our industry. Always write to make debugging easier. Always. There's so many people that worship cleverness over readability.
- xelxebar 10y agoIn all fairness, a stunningly clever insight can make things seem so obvious that you forget how hard it was to have that original insight. This kind of brevity is extremely helpful when thinking about a problem. You "just" have to grok the mechanics thoroughly. This really helps in designing effective higher level abstractions. Unequivocally admonishing brevity for ostensible readability kind of ignores the trade offs. I think there are other ways to bootstrap grokkability without having to sacrifice the conceptual clarity of nicely compact code.
- qorrect 10y agoAs someone taking a lot of ML/AI courses ( a subject new to me) , these clever insights are popping up all around me lately, and I agree once you learn it, it's hard to imagine what it was like before. I'm hitting a lot of 'aha' moments which has really been emotionally satisfying, it's been a long time since I had to push myself I guess.
- sudshekhar 10y agoAs a side, what are some good ways to start understanding the bigger projects? Blogs and documentation are helpful but mostly don't talk about the underlying implementation details. Digging through the code line by line takes a long time and while one does learn a lot, I am sure there has to be a better way of doing this. Any static analysis tools that help in this regard? Or any other tool/approach that you might recommend?
- sealjam 10y agoI am leaving my current team, in part for this very reason. Senior technical people in the organisation don't value readable, understandable code, favouring 150 character one-liners instead. It's proven to be a very effective way of increasing the time taken for anybody except the author to debug issues. In my view, this has increased the perceived value of those responsible. I'm sure that wasn't their ultimate intention but there's certainly no incentive to change!