Linked by Thom Holwerda on Wed 26th Sep 2012 23:25 UTC, submitted by MOS6510
General Development "Having read this, one realization is that better code often means less code. I don't think about lines of code exactly, or something similarly stupid, but in terms of meaningful code. However, argument for less code isn't about making code as compact as possible, avoid redundancy, etc. The argument is about not writing code at all whenever reasonable or possible. Should we focus on deciding what should and what should not built instead of polishing our software development craft then? Yes and no. Yeah, I know. Exactly the kind of answer you expected, isn’t it? Anyway, you can't answer this question meaningfully without a context."
Thread beginning with comment 536666
To read all comments associated with this story, please click here.
Habits and ignorance
by deathshadow on Thu 27th Sep 2012 15:23 UTC
Member since:

Really bad code is bad code, regardless of if it's 'more' or 'less'. More code can often be more efficient or faster -- just ask those of us working in assembly about 'unrolling loops' some time.

Really I think most bad and/or bloated code can be blamed on bad habits. Piss poor inconsistent formatting (It's called TAB and ENTER, USE THEM!), needlessly complex and cryptic variable and function names (because I'm so sure 6 months from now you'll remember what ctx1168v means), pointless overuse of commenting instead of clear code, over-reliance on code 'cleaning' tools like HTMLTidy instead of just writing it properly in the first blasted place, failing to learn the language thanks to using autocomplete as a crutch, etc, etc... In fact a lot of the 'tools' that supposedly make people more 'productive' -- like autocomplete and color syntax highlighting, IMHO reduce the efficiency of the programmer and just promote ignorance. (or in the case of the latter just make code an illegible acid-trip of color where you can't actually see the errors!)

But more than bad habits, it really comes down to the ignorance of the average developer. So often I come across code these days that is brute forcing things the language already has constructs to handle. Sometimes it's simple stuff like the programmer doesn't understand binary... like this gem I just helped someone with in C (checksum is uInt32)

Checksum = (Checksum - ((Checksum / 0x10000) * 0x10000));

Cracked me up, since that mess of divides, multiples and subtracts is just trying to pull the bottom 16 bits... that's AND's job!

Checksum &= 0x0000FFFF;

Functionally identical. I actually was able to speed it up even more by using unit16 that way it didn't even need the AND.

But that's just a simple example -- I just saw some jquery asshattery where the developer was a master of jq stuff -- but was brute force converting a javascript DATE to UTC, then dividing by 1000,60,60,24,etc,etc with endless if statements to calculate the month -- when javascript's DATE object already has methods for extracting seconds, day, month, year, etc... I see that type of rubbish all the time these days, and it just adds to my saying "the only thing you can learn from jquery is how NOT to program javascript". (not that 90%+ of the crap people use javascript for has any business on websites in the first place!)

You see it in PHP all the time -- PHP has a massive function library, you need something done, there is likely already a function to do it for you; but you'll still see people brute-force coding things. In that case at least the massive library can be used as an excuse, but it's still a laugh to see people manually iterating a file directory to dump it into an array instead of just calling the glob function... or manually writing a function to do SHA512 instead of just calling the hash function. You see it all the time, quite often in 'professionally' written software too! But as always, there's a difference between someone working professionally and someone who does professional grade work.

Nowhere do you see inefficient bloated bad code more than you do web development. Decade or more out of date coding practices are still taught as the norm; and along comes the steaming pile known as HTML 5 to just further piss all over accessibility, clean code and minimalism resulting in even more bloated bad code. Worst of all though is the ignorance of the average person writing PHP when it comes to HTML -- a disturbing trend since as a hypertext pre-processor the ENTIRE POINT of PHP is outputting HTML. You look under the hood of turdpress, and you'll repeatedly see the use of classes that show the people making it have NO clue how CSS even works or what inheritance is.

Take the idiotic default markup turdpress LOVES to throw at lists, with title attributes redundant to the content, attributes like TARGET that have no business in markup written after 1998, and endless pointless redundant classes that serve ZERO legitimate purpose when there's a perfectly good class or ID on the parent. If every LI and A inside a UL are getting the exact same class, NONE of them need classes. That's the 'cascading' part of 'cascading style sheets' and it's like the dimwit ninnies writing wordpress templates are completely ignorant of it.

Though that's hardly surprising -- wordpress is for and by people who don't know HTML or CSS... think about that.

Static CSS inlined in the markup, static scripting inlined in the markup (so much for leveraging caching models), non-semantic markup or abusing semantic tags (like lists) out of some 'tables are evil' paranoia (when tables are semantically correct -- for tabular data!) -- it gets worse every year, and this new HTML 5 garbage (at least in terms of markup) does nothing to improve it -- if anything it's the worst of HTML 3.2 all over again!

But, I still remember the lessons I had drilled into me three decades ago when it comes to writing software -- the less code you use, the less there is to break. It's as true writing PHP, HTML and CSS as it was 35 years ago hand-assembling RCA 1802 machine language.

Edited 2012-09-27 15:31 UTC

Reply Score: 4

RE: Habits and ignorance
by Laurence on Fri 28th Sep 2012 08:45 in reply to "Habits and ignorance"
Laurence Member since:

I think it's a little OTT to state that colourised code promotes lazy / bad development. But I do agree with your points about other productivity tools. However, I do think it's also worth baring in mind that modern languages are so complex these days that it would be silly for any developer to memorise every function and parameter. What normally happens is the important / regular APIs are memorised and the less frequent APIs are remembered as "those functions I know exist but need to double check the docs before using".

Static CSS inlined in the markup, static scripting inlined in the markup (so much for leveraging caching models),

While your CSS rants are mostly correct, there is a time and place for inlined scripts / stylesheets. Each new file is a separate page request and can generate quite a bit of overhead. Sometimes it's more efficient to have a small portion of inlined content rather than generating an additional resource file - not just from the user end (as each HTTP request will add quite a bit of bloat for small files) but also from the server end (fewer connections == lower chance of generating your own DDoS attack during peak loads).

Like everything though, there's a time and place for each tool. It's up to the developer to make a professional judgement on which methodology is best suited for each solution. It's just a pity that -as you rightly stated- some developers are not proficient / too lazy to make the best judgement call.

Reply Parent Score: 2