Other peoples code
-
i think the best thing to do for your own coding is to ake it self documenting ergo needing little or no comments if someone can't figure out whats going on fromthe code itself then the code itself is the problem. Something which should be taken into account at the time of writing, not later on :) Readable code is something which needs to be worked on as you code :) cheers Bryce
I totaly agree with John Simmons. Self documenting code is a myth. There is no way for the code to explain why you did it this way. Other than trivial functions you must explain why and what assumptions you are making. It is amazing how smart your were years ago and do not tell me you remember why you coded something last year. Or 10 years ago or 100 years ago, If the product you are supporting has a long life span it may very well be that the code behind it must be kept. So these figures are not made up! "We are what we repeatedly do. excellence, then, is not an act, but a habit." Aristotle
-
I like one exit point too, but a lot of times, that just makes the code hard to follow. Get the exceptions out of the way as early as possible, and then write the business end of the function. Otherwise, you'll have deeply nested code that is a bitch to follow. My rule is that if there's more than three levels of nesting needed to support the desire for a single exit point, it's best not to do it. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio. ------- signature ends
John Simmons / outlaw programmer wrote: Get the exceptions out of the way Good point and I agree. There are allways exceptions. It bothers me when someone blindly follows absolutes that their instructors drilled into them. Even GOTO's have usage at times. I am not saying do not follow good practices. "We are what we repeatedly do. excellence, then, is not an act, but a habit." Aristotle
-
Andrew Torrance wrote: I have a quirk in that my functions only EVER have one exit point , and the first thing I do in any function is to default any returned parameters. Doesn't sound all that quirky to me. :-D Paul I think there're pieces of me you've never seen - Tori Amos, Tear in Your Hand
Look at the code on this site , it is almost universal to find a return in a conditional statement . A single exit point means that return cannot be in such a segment of code. What starts off as trivial can end up growing into something painful. so I avoid things like.. if(MyVariable = true) return(); // The use of bracketted return is another quirk ! Am I the only one forever playing catch up with technology , while all the juicy opportunites keep rolling by ?
-
I like one exit point too, but a lot of times, that just makes the code hard to follow. Get the exceptions out of the way as early as possible, and then write the business end of the function. Otherwise, you'll have deeply nested code that is a bitch to follow. My rule is that if there's more than three levels of nesting needed to support the desire for a single exit point, it's best not to do it. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio. ------- signature ends
Do you follow any 'rules' when handling exceptions ? E.g dealing with them close to where they happen or appending data to them and rethrowing them ? There must be some good ideas on exception handling , but all I ever see are nuts and bolts type articles never any ones on good practices. Am I the only one forever playing catch up with technology , while all the juicy opportunites keep rolling by ?
-
I used to be a style fanatic, wanting everyone to use my coding standards, but over the years I have come to realize the following to be true. Can you read the code and understand its intent? Yes, coding style is good enough. No, something has to change. There are different levels to examine here, layout/names/spacing is the minor, and logic is the major. As long as the code is understandable and the logic is correct don't stress and worry over the minor. Unless its your own code and you are not proud of how it looks! :-D
Justin Hallet wrote: As long as the code is understandable and the logic is correct don't stress and worry over the minor. Fair enough , but what is understandable to one person may be difficult for another if the style used is not what you are used to . Am I the only one forever playing catch up with technology , while all the juicy opportunites keep rolling by ?
-
We all have our own styles of writing , how do you find other peoples styles ? I have a quirk in that my functions only EVER have one exit point , and the first thing I do in any function is to default any returned parameters. Looking at this site I seem to be in a minority of slightly less than two , so what I do must be quirky , anyone else have style quirks ? And how do you get on with other peoples quirks ? Am I the only one forever playing catch up with technology , while all the juicy opportunites keep rolling by ?
Objects should implement their own behaviour. This implies that methods do one thing, not 2, 3, 4. This from what I see does a lot for understanding the code, whether or not you actualjy wrote it. Also good for self-documentation even without // or /*. And also good for component code reusability.
How low can you go ?
(MS rant) -
"Self-documenting" code is a myth. There's no such thing. I don't care how careful you are, reading comprehension and perception of almost EVERYBODY else will be all over the scale. I'm currently dealing with numerous projects where there is little/no comments in the code, and it's driving everybody working on those projects absolutely NUTS. Comment well, and comment often. Use complete sentences and spell correctly to lessen the chances of misinterpretation. Do NOT rely on external tools or the promise of external documentation. Even better, don't rely on anyone else to follow up and comment your code for you when they happen to have to look at it. As far as coding style, don't get any fancier than you need to get. Fancy usually means complex, and complex always means unmaintainable by new team members. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio. ------- signature ends
Hear Hear. No, hear hear!
David Wulff http://www.davidwulff.co.uk
"Unfortunatly Deep Throat isn't my cup of tea" - Martin Marvinski
-
"Self-documenting" code is a myth. There's no such thing. I don't care how careful you are, reading comprehension and perception of almost EVERYBODY else will be all over the scale. I'm currently dealing with numerous projects where there is little/no comments in the code, and it's driving everybody working on those projects absolutely NUTS. Comment well, and comment often. Use complete sentences and spell correctly to lessen the chances of misinterpretation. Do NOT rely on external tools or the promise of external documentation. Even better, don't rely on anyone else to follow up and comment your code for you when they happen to have to look at it. As far as coding style, don't get any fancier than you need to get. Fancy usually means complex, and complex always means unmaintainable by new team members. ------- signature starts "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001 Please review the Legal Disclaimer in my bio. ------- signature ends
I definitely agree with you, John. Additionally, people who aren't expert coders in whichever language your using, might have to come after you to maintain it, for whatever reason. Additional comments will be greatly beneficial to these folks. In both my last two programming jobs, I've had to learn languages while working on projects, and good commenting helped tremendously, thereby saving my employer money. Helping people understand your code, is all about saving time. If an added comment will clarify things later, just do it. No need to be stubborn about it. BW "I'm coming with you! I got you fired, it's the least I can do. Well, the least I could do is absolutely nothing, but I'll go you one better and come along!" - Homer J. Simpson
-
I totaly agree with John Simmons. Self documenting code is a myth. There is no way for the code to explain why you did it this way. Other than trivial functions you must explain why and what assumptions you are making. It is amazing how smart your were years ago and do not tell me you remember why you coded something last year. Or 10 years ago or 100 years ago, If the product you are supporting has a long life span it may very well be that the code behind it must be kept. So these figures are not made up! "We are what we repeatedly do. excellence, then, is not an act, but a habit." Aristotle
Michael A. Barnhart wrote: If the product you are supporting has a long life span it may very well be that the code behind it must be kept. So these figures are not made up! Indeed! Some of the code in our products is 25 years old! BW "I'm coming with you! I got you fired, it's the least I can do. Well, the least I could do is absolutely nothing, but I'll go you one better and come along!" - Homer J. Simpson
-
i think the best thing to do for your own coding is to ake it self documenting ergo needing little or no comments if someone can't figure out whats going on fromthe code itself then the code itself is the problem. Something which should be taken into account at the time of writing, not later on :) Readable code is something which needs to be worked on as you code :) cheers Bryce
bryce wrote: needing little or no comments if someone can't figure out whats going on fromthe code itself then the code itself is the problem. Bollocks. Code with no comments is a nightmare for anyone who isn't the original author. If the variable names are descriptive and correctly identify the uses of the variables, then cool. However some comments to indicate the logic flow, special cases, tricky logic, etc. is a must. --Mike-- "I'd rather you just give me a fish today, because even if you teach me how to fish, I won't do it. I'm lazy." -- Nish Just released - 1ClickPicGrabber - Grab & organize pictures from your favorite web pages, with 1 click! My really out-of-date homepage Sonork-100.19012 Acid_Helm
-
We all have our own styles of writing , how do you find other peoples styles ? I have a quirk in that my functions only EVER have one exit point , and the first thing I do in any function is to default any returned parameters. Looking at this site I seem to be in a minority of slightly less than two , so what I do must be quirky , anyone else have style quirks ? And how do you get on with other peoples quirks ? Am I the only one forever playing catch up with technology , while all the juicy opportunites keep rolling by ?
Andrew Torrance wrote: have a quirk in that my functions only EVER have one exit point I used to do this however, this style tends to increase nesting and a lot of horizontal scrolling has to be done to visualize the whole picture. e.g.
if(FuncA())
{
if(FuncB())
{
if(FuncC())
{
... // Repeat ad nauseum!
}
}
}I now prefer this style
if(!FuncA())
return;if(!FuncB())
return;if(!FuncC())
return;... // Repeat ad nauseum!
There are only 10 kind of people in the world: those who understand binary and those who don't.
-
I also preffer to have one exit point. You have only one place to cleanup what you allocated in the function. /Magnus
- I don't necessarily agree with everything I say
_Magnus_ wrote: You have only one place to cleanup what you allocated in the function. Resource wrapper classes should take care of allocated resources. Even if you only have one exit point, an exception can exit the function from anywhere.
There are only 10 kind of people in the world: those who understand binary and those who don't.
-
You are not alone. Having one exit point for a function is good practice IMHO, and I too default any returned params just to be safe. :)
Faith. Believing in something you *know* isn't true.
Robert Edward Caldecott wrote: Having one exit point for a function is good practice IMHO Well, kindda... in the presence of exceptions your code will exit the function from anywhere.
There are only 10 kind of people in the world: those who understand binary and those who don't.
