Strong code vs working code

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

draco2317
Forum Newbie
Posts: 19
Joined: Mon Sep 18, 2006 9:17 pm

Strong code vs working code

Post 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.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post 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.
User avatar
Chris Corbyn
Breakbeat Nuttzer
Posts: 13098
Joined: Wed Mar 24, 2004 7:57 am
Location: Melbourne, Australia

Post 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.
alvinphp
Forum Contributor
Posts: 380
Joined: Wed Sep 21, 2005 11:47 am

Post by alvinphp »

Since you seem to already know PHP I would pick up a book on PHP patterns and go from there.
jmut
Forum Regular
Posts: 945
Joined: Tue Jul 05, 2005 3:54 am
Location: Sofia, Bulgaria
Contact:

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Strong code vs working code

Post 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.
(#10850)
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Strong code vs working code

Post 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&#39;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.
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Re: Strong code vs working code

Post 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 Image
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Strong code vs working code

Post 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.
(#10850)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
User avatar
onion2k
Jedi Mod
Posts: 5263
Joined: Tue Dec 21, 2004 5:03 pm
Location: usrlab.com

Re: Strong code vs working code

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Re: Strong code vs working code

Post 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.
(#10850)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post 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.
(#10850)
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post 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.
Post Reply