Page 1 of 3
Strong code vs working code
Posted: Tue Sep 19, 2006 12:26 am
by draco2317
I have read in a few different places where people post a script for review, and then recieve replies with completely different code saying theirs is better. While both code seem to work (however one is stronger or more streamlined or whatever).
I mean, lets say i posted one of my websites php script, i am postitive that there would be a lot of lines of code changed, deleted, added, etc, to make the code better. I guess my question is how do you approach building a stronger more efficient code over something that would just do the job.
Posted: Tue Sep 19, 2006 12:42 am
by Luke
that stuff comes with practice... just like any other thing you learn to do... you learn better, faster, easier techniques over time. I find that the best ways to learn techniques and practice are posting my code here for review, and reading books on all matters I don't know about.
Posted: Tue Sep 19, 2006 12:58 am
by Chris Corbyn
I agree with that. Peer review is always a great way to learn from mistakes. If you had the option to do it you could try
pair programming too and see if anything interesting happens

I'll be doing this on a day-to-day basis before long.
Posted: Tue Sep 19, 2006 1:02 am
by alvinphp
Since you seem to already know PHP I would pick up a book on PHP patterns and go from there.
Posted: Tue Sep 19, 2006 1:52 am
by jmut
all said..totally agree.
They are a lot of stuff that should be consider but basically you write code for you to understand. if it works...the computer cares not how it is written (aside performance of course).
So you want to write it...so that if you don't look at it for several months and come back..you know what is what. you avoid duplication so it is easy to maintain....design for testing and easy extendability (design patterns)...oh well

it takes a livetime anyhow. You get a lot of inspiration and ideas of good software books though. So keep reading.
Enjoy.
Re: Strong code vs working code
Posted: Tue Sep 19, 2006 2:22 am
by Christopher
draco2317 wrote:I guess my question is how do you approach building a stronger more efficient code over something that would just do the job.
Peer review, refactoring, and test driven development are the premier methologies today to do what you are looking for.
Re: Strong code vs working code
Posted: Tue Sep 19, 2006 3:25 am
by onion2k
arborint wrote:Peer review, refactoring, and test driven development are the premier methologies today to do what you are looking for.
Note that very, very important word. Today. They're the latest fashion. They're not a wonderful code panacia that will answer all your development ills.
All object orientation, patterns, pair programming, tdd, etc actually do is formalise the way people develop software. If you've already got a system that works well for you then there's no compulsion to change, especially if that means you'll end up producing worse code. Software developers are notoriously disorganised and lazy (yes we are) .. all these fashions in development try to do is make sure everything actually gets done.
Also, there's a much larger proportion of people in the software industry who have learnt to program at university these days rather than being self-taught. Academia is always coming up with new and exciting things to teach people without actually understanding what goes on in the real world. Much as I'm loathe to say it, sometimes quick'n'dirty code is better. If you're working for a small company occasionally you'll need to consider things like cash flow when you're writing something .. sometimes you'll need to bang out some code as fast as possible just so you can get the invoice out .. if you insist on using TDD and refactoring in that sort of situation then you won't have a job any more because the company will have gone under.
The rule is really that you should write the code that best suits the job. If you have plenty of time, money in the bank, and a client that will be paying for you to maintain the code, then write the highest quality software you can. If you need the money now, or the code is just a one-off noone will ever visit again, <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> it, chuck out something that works and to hell with the standards. You've got to live in the real world.
Re: Strong code vs working code
Posted: Tue Sep 19, 2006 3:31 am
by Luke
onion2k wrote:arborint wrote:Peer review, refactoring, and test driven development are the premier methologies today to do what you are looking for.
Note that very, very important word. Today. They're the latest fashion. They're not a wonderful code panacia that will answer all your development ills.
All object orientation, patterns, pair programming, tdd, etc actually do is formalise the way people develop software. If you've already got a system that works well for you then there's no compulsion to change, especially if that means you'll end up producing worse code. Software developers are notoriously disorganised and lazy (yes we are) .. all these fashions in development try to do is make sure everything actually gets done.
Also, there's a much larger proportion of people in the software industry who have learnt to program at university these days rather than being self-taught. Academia is always coming up with new and exciting things to teach people without actually understanding what goes on in the real world. Much as I'm loathe to say it, sometimes quick'n'dirty code is better. If you're working for a small company occasionally you'll need to consider things like cash flow when you're writing something .. sometimes you'll need to bang out some code as fast as possible just so you can get the invoice out .. if you insist on using TDD and refactoring in that sort of situation then you won't have a job any more because the company will have gone under.
The rule is really that you should write the code that best suits the job. If you have plenty of time, money in the bank, and a client that will be paying for you to maintain the code, then write the highest quality software you can. If you need the money now, or the code is just a one-off noone will ever visit again, <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> it, chuck out something that works and to hell with the standards. You've got to live in the real world.
A++ Great Advice

Re: Strong code vs working code
Posted: Tue Sep 19, 2006 10:21 am
by Christopher
onion2k wrote:Note that very, very important word. Today. They're the latest fashion. They're not a wonderful code panacia that will answer all your development ills.
I need to strongly disagree with this. Fashion is something that is interesting simply because it is different, not functionally superior. The methodologies the culminations of great minds building upon successes and failures to produce something functionally superior.
onion2k wrote:All object orientation, patterns, pair programming, tdd, etc actually do is formalise the way people develop software. If you've already got a system that works well for you then there's no compulsion to change, especially if that means you'll end up producing worse code. Software developers are notoriously disorganised and lazy (yes we are) .. all these fashions in development try to do is make sure everything actually gets done.
Software is something notoriously difficult to design and develop well. When you say,
"All object orientation, patterns, pair programming, tdd, etc actually do is formalise the way people develop software. " That is a very big ALL -- in fact it is everything.
onion2k wrote:Also, there's a much larger proportion of people in the software industry who have learnt to program at university these days rather than being self-taught. Academia is always coming up with new and exciting things to teach people without actually understanding what goes on in the real world. Much as I'm loathe to say it, sometimes quick'n'dirty code is better. If you're working for a small company occasionally you'll need to consider things like cash flow when you're writing something .. sometimes you'll need to bang out some code as fast as possible just so you can get the invoice out .. if you insist on using TDD and refactoring in that sort of situation then you won't have a job any more because the company will have gone under.
This is a very old arguement that ignores the truth that most of programmers work is supporting code rather than writing code. You comments make the assumption that programming is a switch with only two settings: "quick'n'dirty code" and "TDD and refactoring" where the reality is that best practice methodologies take things like this into account and provide a spectrum.
onion2k wrote:The rule is really that you should write the code that best suits the job. If you have plenty of time, money in the bank, and a client that will be paying for you to maintain the code, then write the highest quality software you can. If you need the money now, or the code is just a one-off noone will ever visit again, <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> it, chuck out something that works and to hell with the standards. You've got to live in the real world.
Again, "write the code that best suits the job" implies that you simple cannot apply best practices to many jobs. I think that twists the reality of development methologies. My experience as an independent developer is that if my code is not good from the start I will lose my shirt supporting it.
Posted: Tue Sep 19, 2006 10:37 am
by RobertGonzalez
Write your code. Have it reviewed by peers. Use your code (as long as it is secure). Go back in a few months and try to decipher your code. Discover the inefficiencies, then rewrite it better. In the meantime, come here, contribute to the community in a way that allows you to learn at the same time as you teach, and before you know it, you will be smokin as a developer.
Re: Strong code vs working code
Posted: Tue Sep 19, 2006 10:52 am
by onion2k
arborint wrote:Again, "write the code that best suits the job" implies that you simple cannot apply best practices to many jobs.
Actually thats the opposite of what I meant. In most circumstances you should be applying best practises to the code you write .. but those practises depend on who you are and how your company works. What I'm saying is that there isn't a solution to writing maintainable code that will work for everyone. You need to be flexible. Defining working practises is no different to defining a coding standard .. lots of people have different ideas about what's best. You need to find what works for you and your team. Stubbornly insisting on objects, patterns, tdd, or whatever isn't always going to lead to the best possible scenario. It will in a lot of situations, but you need to remain open to other ideas too, even if they'd make a university lecturer cry.
Re: Strong code vs working code
Posted: Tue Sep 19, 2006 11:45 am
by Christopher
onion2k wrote:arborint wrote:Again, "write the code that best suits the job" implies that you simple cannot apply best practices to many jobs.
Actually thats the opposite of what I meant. In most circumstances you should be applying best practises to the code you write .. but those practises depend on who you are and how your company works. What I'm saying is that there isn't a solution to writing maintainable code that will work for everyone. You need to be flexible. Defining working practises is no different to defining a coding standard .. lots of people have different ideas about what's best. You need to find what works for you and your team. Stubbornly insisting on objects, patterns, tdd, or whatever isn't always going to lead to the best possible scenario. It will in a lot of situations, but you need to remain open to other ideas too, even if they'd make a university lecturer cry.
I can only strongly disagree with you. There is broad concensus about best practices for software development, with the same set of ideas evolving for the past 50 years. Stubbornly resisting objects, patterns, tdd, or whatever because you have some axe to grind with university lecturers does not make sense to me -- especially given the breadth and depth behind those things you mention.
It is interesting that you say
"What I'm saying is that there isn't a solution to writing maintainable code that will work for everyone. You need to be flexible." because what you are saying is -- Don't be flexible in adopting best practices, be flexible in ignoring them. Ignoring good practices is not the flexiblity that, in my experience, programmers need more of.
Posted: Tue Sep 19, 2006 12:05 pm
by RobertGonzalez
Standards can be set by an individual or organization. Best practices are usually developed by an industry. But just because they are best practises doesn't mean they are end-all, be-all to everything related to your industry. They are just what are commonly accepted values related to your industry. That is why there are best practises AND standards. The key is to adopt one and follow it consistently within the scope of control for your position. They cannot be imposed on others and typically attempting to do so results in frustration and opposition.
Posted: Tue Sep 19, 2006 1:21 pm
by Christopher
I am regularly confused by these converstations. It sounds like you are saying that because best practices are not "be-all, end-all" that you should choose worse practices? I guess I am not clear about why one would stubbornly stick to worse practices when there is such a wealth of information about better ones available. I know that personally I have many bad programming habits that I work hard to get rid of. It is a continuous process and I certainly would not want to head the other direction.
Posted: Tue Sep 19, 2006 1:27 pm
by RobertGonzalez
Well, I suppose I should claify that choosing to adopt a standard that is not exactly in line with the Best Practises of an industry does not in any way imply the use of worse standards. Who said that Best Practises are the best methods? Who said those methods will fit my business rules within the scope of my need for the technology in that industry?
What I am saying is that, while best practises exist, there needs to be some common sense applied to the adoption of those practises. Just because someone puts a list of ideals into a collection called best practises doesn't make them the best way. Moreso if you get more specific to an field within the industry. However, a standard can be developed that is visible, clearly spelled out and clearly agreed upon by those members utilizing that standard in a way that makes deviating from that standard as visible as the standard itself. This ensures consistency and the commonization of practises within your scope of work within your area of the industry in which you are a part.
I may not be stating my position correctly, but I am not advocating 'worse practises' by saying that best practises are not necessarily relevent to a particular segment of an industry.