|
Maintainability implies readability but not vice-versa.
Extensibility implies maintainability but not vice-versa.
Kevin
|
|
|
|
|
This is realy interesting question..
but wasn't there similar poll some time ago?
If yes, than this is first poll repost in history of ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) ...
I'm not sure what to vote because when I was writing school projects it was very important to write extensible code (so i was able to add new features when I had time).. but this is not "real-life" answer...
|
|
|
|
|
This was a very interesting survey. Having as few bugs as possible is always a goal, but the main goal depends on what I'm writing.
Right now, I'm developing a plug-in architecture for a program I'm working on, so Extensibility is a primary concern. A non-extensible plugin framework isn't very useful.
But, if I'm writing a single-purpose section of code not meant to be used outside of a component, I'm not going to worry about extensibility as much.
|
|
|
|
|
My goal is to write the least amount of code possible to get the job done, that typically means less readibility for other people, but I don't care. The main thing to me is bug free, fast and resource efficient code. Writing small, clever code also means better maintanibility too, because instead of messing with the main code, you could just work with the variables to make most changes. The end user is not going to see how much work you put into readibility, but they are going to see if the code is slow or buggy.
|
|
|
|
|
Kyle Edwards wrote:
...typically means less readibility for other people, but I don't care.
In my case, that means less readability for myself if I need to come back to the code a week or a month or a year down the road. I'd much rather get to get to coding than spend precious minutes or hours trying to figure out my thought process when I wrote it the first time.
Kyle Edwards wrote:
small, clever code also means better maintanibility...
I certainly can't agree with you there. I used to give myself points for "cleverness" when writing code, but it generally got me into trouble later on.
Compilers couldn't care less whether the code is clever and obfuscated or simple and readable. Source code is for humans, so why not make it easily readable? Maybe coding in Perl is what turned me around, because it's not very difficult to get yourself lost in your own code. You can do it with C#, too, but thankfully it's a bit harder.
Charlie
if(!curlies){ return; }
|
|
|
|
|
I may be wrong, you guys probably have more experience than I do. But for me, writing a function in a clever way can mean not having to mess with the code later, just changing the values that go into it, because it will typically be more versaitle.
Kyle
|
|
|
|
|
Sorry, have to agree with Charlie here. Never seen any code that wasn't revisited at least a couple of times after I thought it was the final, final final version. If I was lucky, I'd remember what I did. More often, I would not. I started using really descriptive variable names etc. Sure, be as clever as you want, but be sure to document that cleverness so that some months later, you can come back and read through it and understand what you did.
|
|
|
|
|
Charlie Williams wrote:
Maybe coding in Perl is what turned me around
I'm not surprised! Perl is the worst language I've ever had the misfortune to use. I always used to leave work in a foul mood whenever I encountered it. Perl makes C look like a model of clarity.
Kevin
|
|
|
|
|
I haven't written anything in Perl for some time now and can't say for certain whether I ever will again. It can be quite productive and satisfying when you're "in the zone", but I've always found it so difficult to come back to my own work that it's almost not worth it in the first place.
I'll take C# over Perl any day, although they don't really lend themselves to comparison. I certainly use C# for different reasons than I used Perl.
Charlie
if(!curlies){ return; }
|
|
|
|
|
Charlie Williams wrote:
but I've always found it so difficult to come back to my own work that it's almost not worth it in the first place.
That's why Perl has been described as "write once, read never." See "What's wrong with Perl?" http://www.garshol.priv.no/download/text/perl.html[^]
Yes, Perl should be compared with other scripting languages rather than C#. At the time I was pulling out what's left of my hair over Perl, I discovered Python and found it far nicer and much more congenial to C/C++ developers, despite its initial strangeness.
Kevin
|
|
|
|
|
Kyle Edwards wrote:
write the least amount of code possible to get the job done
That's a worthwhile goal, as long as you keep it in the view of Keep It Simple Stupid. 'Clever' code, where you manage to take a simple but verbose algorithm and turn it into tight but convoluted code, is a monumental pain in the ass over the long term. While the verbose version may have been annoying to write, it will be a lot easier to maintain as time goes on because it won't take you as long to remember how it works.
Kyle Edwards wrote:
typically means less readibility for other people, but I don't care
That statement tells me several things:- Your work by yourself, or in a very small group.
- Other people only use your code in its executable form; coworkers don't have to step through your code in a debugger, for example.
- You have limited experience. I doubt you've ever been on a programming project that lasted more than a couple of months, or required the efforts of more than two or three people.
I'm going to take a harpoon to your bubble here. As long as you're willing to stick to working on little projects, this attitude will work. Unfortunately, little projects that support you are not easy to come by.
Your approach wouldn't work on my team. We're working on phase 2 of a piece of software. Phase 1 took 2 years to complete, and it started with an initial framework from another product. Phase 1 is running successfully at a number of customer sites.
We are a team of only five programmers. Almost every day we end up stepping through each other's code as we debug our own. If any one of us didn't care about writing readable and understandable code, the whole project would either bog down or fail outright. If I can't understand what your code is doing as it interacts with mine, how can I judge whether the bug is in my code or yours? My initial reaction, if I can't understand how your code works, is that the bug is yours.
Software Zen: delete this;
|
|
|
|
|
Kyle Edwards wrote:
that typically means less readibility for other people, but I don't care
That worries me. I get worried when people say things like they don't care with issue that are actually quite important. As others have said it is quite normal to revisit code that you may have thought was finished with. 8 years on I still get calls occasionaly about code that I wrote when I was fresh out of university - luckily I quickly realised that maintainability was important and wrote code accordingly so at least if a call comes through I can see what I was doing.
Kyle Edwards wrote:
The main thing to me is bug free, fast and resource efficient code
Bbug-free is near impossible in modern software and fast and resource-efficient are usually trading off against each other.
Kyle Edwards wrote:
The end user is not going to see how much work you put into readibility, but they are going to see if the code is slow or buggy
Depends who the end user is. One of the projects I am currently working on the end users are other developers (I'm working in a team that is developing an API for the end client), so readability is a major factor. However, even if the end user is just a person who will use your web application, readability and maintainability are still very important because most software will go through many revisions and upgrades and RFCs (requests for change) will arrive and so on and frequently bugs arrive just as the person who wrote the code has gone on holiday or just left the company and some one else has to pick up the pieces.
I see from your profile you're still quite young, so you have not been exposed to the commercial world of software development yet. Once you have been I am sure you'll discover that readability is a major factor in writing good solid code.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
Sorry, I was wrong. Thanks for the input all of you, I'll rethink my methods. I have only been programming for a couple of years, and am still learning.
|
|
|
|
|
Kyle Edwards wrote:
Sorry, I was wrong
Few people ever admit that. That is a major plus, even if you only ever admit it to yourself. I used to work with a guy who, when he realised he was wrong, would change his mind and never admit to having had any other thoughts - but at least he saw the light in the end.
Kyle Edwards wrote:
and am still learning
That never ends. I've been programming for 21 years and I am still learning. I don't ever expect, or intend, to stop.
"You can have everything in life you want if you will just help enough other people get what they want." --Zig Ziglar
The Second EuroCPian Event will be in Brussels on the 4th of September
Can't manage to P/Invoke that Win32 API in .NET? Why not do interop the wiki way!
My Blog
|
|
|
|
|
You admit that you were wrong and that you'll rethink your methods. That's a great attitude. Few people are prepared to do that (or aadmit it). So, after earlier saying I wouldn't hire you, I'll admit that I was wrong and I would hire you.
Kevin
|
|
|
|
|
As you become a more experienced programmer you will understand that there are two kinds of efficiency relating to code design. The first is run time efficiency, which is very important. The second is maintainability and extensibility efficiency, which is probably even more important to a typical application developer.
The end user is probably not going to care much about whether your code runs a few nano-seconds slower than it might. But they will certainly notice when it takes you six months to get promised feature improvements in their hands because your clever code was not originally designed with that in mind.
You should always design your code keeping in mind the very real probability that it will need to be changed, possibly radically, during its lifetime. The faster you can respond to changing user demands the more succesful your application will be. You are probably not going to be able to do that by working "with the variables" (A comment which I'm not sure I even understand, but which leads me to suspect that you are already corrupted with a vb mindset.)
|
|
|
|
|
I fully agree with you. Few miliseconds difference in performance hardly matter to customer. They always want a finished product within specified time frame. Whether it is a bug fix or new enhancement request customers expect it in time. If our code is not organised enough then it is very very hard to finish the request in time. I have a lots of experience in this regard.
|
|
|
|
|
I would not hire anyone with this attitude.
Kevin
|
|
|
|
|
I realise a lot of nice people here have disagreed with what you have stated. But I happen to agree, under one condition, that you are a good enough coder to do it.
Just last Friday I had a IT chap call me to say that an algorithm that I had implimented 21 yrs ago was to celebrate it's birthday. The business' only issue is how to port it from FORTRAN 66 to a newer technology. (Information was left as to how the problem was initially solved, but guessing at future porting is silly.)
Anyhow if you are really good nobody will ever need to alter the internals of your code, however its useful for extendability to elucidate on how functions and procedures should be correctly used. This is turn should give enough clues in the rare case that anyone actually needs to modify your code.
Regardz
Colin J Davies
Attention: It's finally arrived, The worlds first DSP.
|
|
|
|
|
I see that if you make the code to be easily extensible, then it is also easy to maintain. To make bug free code is rather impossible task to do, if we keep in mind that bug doesn't need to bee pure programming technical issue (e.g. null pointer etc.) And what a bigger the app is, the more bugs it will have. E.g. end user will sooner or later do something that you never thought about. As parthchak said somewhere above, more important is to find and fix bugs as quick as possible when they occur.
|
|
|
|
|
..but maybe its extensible in that the way that you can add classes and objects to the project... but the internal messaging is so screwed up... it's not maintainable and takes a lot of figuring out and experimentation to get it to work.
 )
|
|
|
|
|
See my thread titled "Some inter-relationships" above. To express it precisely, extensibility implies maintainability but not vice-versa. In other words if it's not maintainable then i twon't be reliably extensible.
Kevin
|
|
|
|
|
What about the reverse?
Maintainable is also extensible.
And what about some other possible views?
Maintainable is also being easily readable by others.
Maintainable also means it is easier to fix bugs..
|
|
|
|
|
I disagree. It might be a complete mess, and yet it might be clear that you just have to copy a chunk of mess and tweak it to add a new feature.
On the other hand, if it's easily maintainable then it's easily extensible.
|
|
|
|
|
Stupid users are incredibly good at finding bugs 
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
