| News | Features | Interviews |
| Blog | Contact | Editorials |
| Code better or code less? |
| By Thom Holwerda, submitted by MOS6510 on 2012-09-26 23:25:23 |
| "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." |
|
| Habits and ignorance |
| By deathshadow on 2012-09-27 15:23:41 |
|
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 |
 - Score: 4 |
| Comment by Radio |
| By Radio on 2012-09-27 17:29:36 |
|
Seriously guy, this is not rocket science: http://xkcd.com/844/ |
| - Score: 3 |
| RE[3]: Eloquence |
| By lucas_maximus on 2012-09-27 17:56:19 |
|
Generally yes, however I see regularly where people have just put in a try ... catch instead of actually understanding and dealing with the route cause (Checking for the obvious condition, such as null object). Most bad code comes from one of the following: * Inexperience. * Not Invented Here (NIH) syndrome. * Re-inventing the wheel. * Not using standard libraries (inability to Google or use API docs). * Lack of coding standards or code reviews. * General Management WTFs. * Policy problems (you are not allowed to change this because of x, y and z, which are all retarded problems) * Hacks due to laziness, or lack of understanding (happens a lot in Web development with either JavaScript or Internet Explorer). * People that don't have any professional integrity. |
| - Score: 2 |
| RE[2]: Eloquence |
| By DeepThought on 2012-09-27 18:18:44 |
|
> shorter code != maintainable code. Hell, no. Or yes ?! Your point is to general. I'm sure any decent programmer wrote code that proves your point correct and also wrong. |
| - Score: 1 |
| RE[3]: Eloquence |
| By Alfman on 2012-09-27 19:56:39 |
|
DeepThought, That's the problem, these are nice abstract ideologies but they're meaningless in practice since everything is relative. Write as much code as you need, but no more! Well, that almost goes without saying, but it doesn't acknowledge the evolutionary processes that software undergoes to get from A to Z. Like others have said, sometimes more code is better than less, there are so many factors that need to be considered (ie modular versus hardcoded, efficient vs simple, quickly hacked together vs long term managability). It would be ignorant to push forward an absolute ideology up front without even taking into account the specific requirements of a project. |
| - Score: 3 |
| Comment by Luminair |
| By Luminair on 2012-09-28 05:34:29 |
| the best code is the stuff that someone else can pick up and understand and work on the quickest!!!!!!!!!!! |
| - Score: 2 |
| RE[3]: Eloquence |
| By Laurence on 2012-09-28 06:10:17 |
|
> > shorter code != maintainable code. Hell, no. Or yes ?! Your point is to general. I'm sure any decent programmer wrote code that proves your point correct and also wrong. Which is exactly what I said. Edited 2012-09-28 06:13 UTC |
| - Score: 2 |
| RE: That depends |
| By Laurence on 2012-09-28 06:19:59 |
|
> For me, better code means any other person can understand the workflow and the purpose of that code without needing 1,000 pages long manual/information. That means, in most scenarios, that the code will be suboptimal (when compiling and running it). So, the real question would be "code faster or code readable"? Sub-optimal code would be useless for kernels or real time systems. Plus the reason for code comments is to make code readable. So there's little point, in my opinion at least, of writing deliberately crippled code just to make it readable. That said, I don't agree with needlessly obfuscating code just for the sake of gaining a few clock cycles either. So we're back to the earlier points at the top of this discussion: that there's a time and place for every methodology. |
| - Score: 3 |
| RE[4]: Eloquence |
| By DeepThought on 2012-09-28 06:36:01 |
| Sorry, then I missed your point. |
| - Score: 1 |
| RE: Habits and ignorance |
| By Laurence on 2012-09-28 08:45:50 |
|
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. |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |