| 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." |
|
| better or not |
| By zhulien on 2012-09-27 02:48:14 |
| Better code is better because it suits it's task better. Sometimes it is smaller, sometimes it is faster, sometimes it is more maintainable, sometimes it is easier to debug, sometimes it is easier to change, sometimes if you are extremely lucky, it is all. All good programmers will realise they will always have ways to improve and inprove the way they do things over time when they have the opportunity. I'm being very broad, because a good program designed to run in 2kb on a Z80 based micro controller is going to have different requirements and constraints likely a good program that is to run on a modern desktop computer. |
 - Score: 5 |
| The Dao |
| By kwan_e on 2012-09-27 05:18:33 |
|
"The Dao that can be spoken is not the Eternal Dao. The name that can be named is not the Eternal Name." You can't really define the best code until you've come across it, and it's usually not very general purpose. Personally, I find the Halstead metric a good heuristic while I'm writing code. I think it's much better than Cyclomatic Complexity because it is more cargo cult programming than scientific. A problem requires as much cyclomatic complexity as needed, not some arbitrary number. However, the number of unique operands and operators over the total number of operands and operators in use are still a very good sign of whether you've overcomplicated something. It's also somewhat generalizable to design as well replacing operands for classes/servers/clients/sub systems and operators for states. Keep one or the other as low as possible while coding/designing/documentin g. |
| - Score: 2 |
| Good tool and future |
| By marc.collin on 2012-09-27 08:36:40 |
|
i think there are a lot of great tool now to have an idea where programmer need to improve. Also, i think tool who generate code could be a good solution, surely it's the way to go... there are lot of reasearch about this kind of tool. |
| - Score: 1 |
| That depends |
| By franzrogar on 2012-09-27 08:54:52 |
|
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"? |
| - Score: 2 |
| Eloquence |
| By Lennie on 2012-09-27 09:13:10 |
|
Programming languages are like other languages if you ask me. An experienced programmer is probably more eloquent in defining what he/she wants the code to do when using programming languages and he/she is also more likely to be more eloquent in the programming language of choosen. An experienced programmer is also more likely to make better code, which is more generic or to the point and probably also better at choosing which code should be to the point or generic. So an experienced programmer is more likely to make better code and because of the eloquence you also get shorter code. This means shorter code (because of the programmers experience and knowledge) is usually faster and all the other properties you mentioned. But hey, that is just my opinion ;-) |
| - Score: 2 |
| RE: Eloquence |
| By Laurence on 2012-09-27 11:04:51 |
|
shorter code != faster code. For instance, if I were writing a video codec, faster and better code would be using hardware frame buffers as opposed to purely software rendering. However using hardware acceleration adds a lot of code as well as complexity. shorter code != maintainable code. Modularising code can lead to easier debugging (as classes can be tested in isolation), and better maintainability in many cases too. However modularisation produces more verbose code. However I think the OP was the most accurate when he stated that "Better code is better because it suits it's task better" - ie there is no definitive rule stating code most comply to x, y and z as the circumstances will vary depending on the project. (case in point, I've written some horrible kludges before because it made the most sense for that particularly project to patch the code in the crudest possible way given the time constraints and the (lack of) significance of the routine that was being patched). Edited 2012-09-27 11:10 UTC |
| - Score: 5 |
| RE[2]: Eloquence |
| By Lennie on 2012-09-27 11:07:49 |
| My point was: if the programmer sucks at programming you'll probably end up with much more code which ends up doing the same thing just slower and probably more buggy. |
| - Score: 2 |
| RE[3]: Eloquence |
| By Laurence on 2012-09-27 11:27:29 |
|
> My point was: if the programmer sucks at programming you'll probably end up with much more code which ends up doing the same thing just slower and probably more buggy. Yeah, but that's got nothing to do with this topic what-so-ever as crap developers will write crap code irrespective of best practises. |
| - Score: 2 |
| RE[2]: Eloquence |
| By zhulien on 2012-09-27 11:44:16 |
| Agreed, shorter code much of the time is slower, it can sometimes be more difficult to understand if the complexity to make it shorter increases (not always). The fastest text output routine for example on the Amstrad CPC is about 2 kilobytes because it has masses of repeated LDIs and sequential arithmatic operations without many loops where-as the simplest is about 25 bytes - but takes ages comparison to render - important when you are trying to synchronize things in a Demo or Game, but less important when writing a business application - but then that 2 kilobytes might be more precious than the speed - ah such trade offs... to achieve 'better' code. |
| - Score: 2 |
| The Best Code |
| By Alfman on 2012-09-27 14:32:04 |
|
...is a futile metric. Sure there's good code and bad code, but it draws focus away from the solution itself and nit-picks at the implementation. Often times the developers are hired/contracted to implement totally asinine solutions for any given problem. The best code in the world isn't going to be appreciated by the users if the solution doesn't work for them. Who is good code important to? It's important to us as developers. But in my experience users & clients don't care, at least as long as the developer is able to manage the mess (which isn't always a given). A specific example I'm fighting with alot these days is OSCommerce. Unfortunately, the code is very poorly written. It is dependent upon php's notoriously problematic "magic quotes" feature. It supports a kind of plugin, but these lack modularity therefore each plugin needs to patch the base source code. Source patches often overlap with one another and our own customisations such that adding new plugins is error prone and not straightforward. These source patches are inherently version specific. Each adjustment we must make locally puts the code base that much further from the mainline. Software updates are non-trivial, which is a major problem due to OSC vulnerabilities. Also, there is tremendous functional overlap between include files of the website and administration panel, resulting in twice the maintenance burden. So I hate OScommerce code, but it happens to be included at most hosting providers, and because of that many users will try it out and consider it a good base solution for their website without having looked at the code. Edit: My conclusion is that both solution and the code are important, but they are important to different people. Edited 2012-09-27 14:34 UTC |
| - Score: 2 |
| News | Features | Interviews |
| Blog | Contact | Editorials |