Re: Does bad code really teach you to write good code?
by strat (Canon) on Jun 17, 2005 at 08:08 UTC
|
Well, I'm only on the long long way of trying to become a perl veteran, but here are my 2 cent
In my opinion you need a bit of both. You need at least one big mess of program you have to change to find out why to do proper programming and what not to do, and a good perl programmer to explain some problems that are not so obvious (you can tell a kid twenty times that fire is hot; but this is not so effective as if it feals the heat, since then it will know it forever)
On the other hand you need good code to find out some possibilities how you can do something, and improve your way of coding.
And very important is to have to change code you wrote some months/years ago
Best regards,
perl -e "s>>*F>e=>y)\*martinF)stronat)=>print,print v8.8.8.32.11.32"
| [reply] |
Re: Does bad code really teach you to write good code?
by Ninthwave (Chaplain) on Jun 17, 2005 at 07:53 UTC
|
It depends on how the programmer learns. There is no one learning method. I for example learn by reading, doing, fixing, reading, doing fixing. I have learnt more recently than ever by having more code to maintain. Before coding was writing functional one offs. Lately I have had to update my code and extend functionality. And that has made me better just because coming back to a 1 year old code, you learn the need to document and write readable code not just functional code. I think having to use other people's code or maintain the code of others would have the same affect. I am not a great coder and will always be learning. Who knows maybe as I get to different levels of understanding my learning methods will change also.
"No matter where you go, there you are." BB
| [reply] |
Re: Does bad code really teach you to write good code?
by Tanktalus (Canon) on Jun 17, 2005 at 13:08 UTC
|
Good decisions come from experience. Experience comes from bad decisions. But you need to know they're bad. If you're writing bad code, but think it's good code, you won't learn from it. So, I'd say it takes practice maintaining bad code to know how to write good code. :-)
| [reply] |
|
|
| [reply] |
Re: Does bad code really teach you to write good code?
by dragonchild (Archbishop) on Jun 17, 2005 at 13:34 UTC
|
"Writing" code is a process. Probably about 80% of the process has nothing to do with typing. It's that 80% that determines "good" code vs. "bad" code, and getting that 80% right is just a matter of experience. If you're lucky, you are put on a project maintaining a ton of bad code early in your career. Otherwise, find some CPAN projects and help out. There's nothing like getting in the trenches to learn how stuff can go wrong in a heartbeat.
- In general, if you think something isn't in Perl, try it out, because it usually is. :-)
- "What is the sound of Perl? Is it not the sound of a wall that people have stopped banging their heads against?"
| [reply] |
|
|
The situation I'm currently in doesn't give me the opportunity to work with existing code. I'm doing nearly everything from scratch (except for using modules). While I've been reading and examining code from anywhere I can get my hands on; one of the things I lack is a peer I can go to who can help me identify the parts of my code that while functional could be written better. That is what I hope to get from perlmonks.org.
| [reply] |
|
|
If you have a test suite, then it doesn't matter how your code was written - you can always refactor it.
My criteria for good software:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
Re: Does bad code really teach you to write good code?
by jordanh (Chaplain) on Jun 17, 2005 at 13:21 UTC
|
"Experience is a dear teacher, but fools will learn by no other" - Benjamin Franklin | [reply] |
|
|
Nice quote I'll have to rememeber it.
| [reply] |
Re: Does bad code really teach you to write good code?
by samizdat (Vicar) on Jun 17, 2005 at 14:13 UTC
|
A good approach is to start from the place that your code could be either bad or good. Once it actually works, as in, solves the problem, realize that that's the most important thing.
Ask yourself how clearly visible the solution logic is. If your program flow jumps right out at you and doesn't need explanation, it has a chance at being good code. Ask your cow-orker if he/she can see it as clearly and explain it.
Then, as has been posted, go find some samples of other code and try to understand it. It doesn't matter if the code is considered "good" or "bad", only that it's somebody else's. Pay attention to your own internal conversations while looking over the code. What questions are you looking to answer?
One of the problems inherent in looking at other peoples' code is that everybody's idioms are different, and everybody's "working subset" of Perl is different. Code that's a natural for an OO Perl addict is obtuse to someone from the dark ages (like me) who thinks parentheses have their uses and IF should come before THEN.
More important than syntax is to understand the various patterns of coding in modular fashion. Here's a good exploration to start with. It's more important to learn how to approach a problem in an analytical manner than it is to learn from the bottom up what "good code" is, although writing code that mirrors the flow WILL help you maintain your program DTR.
Bad code -- or rather, the maintenance of bad code -- does teach one a lot. I've had the good fortune of being asked to maintain both good code and bad (hey, I did get paid to do it!), and both experiences have helped me greatly. I've also had to go back and look at my own work many a time, and the view from after another turn of the spiral always yields more insight. "Good code" is such a moving target. Good code is code that works and can be understood by another, no matter what set of idioms it uses. Elegant code is in the eye of the beholder, and, once again, it's more in the problem solving approach than it is in the details of the code.
Of course, doing your best to emulate good code writers will get you much further than hanging with slackers! < grin > :D | [reply] |
|
|
Thank you very much for the good advice I plan on reading the guide on my night off so I can really enjoy it.
| [reply] |
Re: Does bad code really teach you to write good code?
by tilly (Archbishop) on Jun 18, 2005 at 01:53 UTC
|
People learn to discern quality by having multiple examples to compare and (most importantly) contrast. If all code that you deal with is good, then you'll never learn what makes it good - it just seems to naturally flow. If all code that you deal with is bad then you have no positive role models for your own code. Therefore you need exposure to both.
What is more helpful than exposure, though, is exposure with feedback from someone who can explain what to look at, why one is better than the other. (Feedback from trying to analzye the results of your project is also helpful.) Exposure to books that try to explain this is better than nothing, but far from perfect - we each make individual kinds of mistakes and books will only help you if your mistakes happen to match the ones that the books are trying to address. | [reply] |
Re: Does bad code really teach you to write good code?
by Anonymous Monk on Jun 17, 2005 at 07:50 UTC
|
Depends on you.
Compare this months code to code from 3-6-12-... months ago.
With more experience you should have a better idea of what is bad code.
| [reply] |
Re: Does bad code really teach you to write good code?
by bofh_of_oz (Hermit) on Jun 17, 2005 at 13:29 UTC
|
My opinion is - it largely depends on the person writing the code. Everyone will write bad code in the beginning, but one should re-read the code after the errors have been found, and think/meditate on how that should have been done better, and why (very important!). That way the person will learn; otherwise, they probably will just continue to write bad code over and over without understanding the principles of good programming.
--------------------------------
An idea is not responsible for the people who believe in it...
| [reply] |
Re: Does bad code really teach you to write good code?
by Your Mother (Archbishop) on Jun 17, 2005 at 18:20 UTC
|
Lot of good comments already. You can learn both ways. One is better though and will save you much misery. Remember, hacking and teaching are not the same discipline.
Every time you sit down to code, you are practicing. Just like with a physical task like martial arts or sports, if you practice wrongly (poor technique, no warm-ups, random effort) you might improve but it will be slow and you will hit limits of how much you can improve very quickly. Additionally, you will have ingrained things that will be harder to undo than if you'd just started correctly when you began.
I can think of no other site like this for any discipline where so many experienced, talented, patient professionals are willing to guide the uninitiated with personalized advice and tutorials that would cost thousands of dollars in the real world. Just visiting and reading here on a regular basis will save you hours if not years (and not just as a beginner; I've been using perl for 7 years now and I learn something almost every time I visit). Everyone writes bad code at first. How much bad code you end up writing is quite negotiable.
| [reply] |
|
|
It sounds like good advice and I will keep it in mind. Thank you.
| [reply] |
Re: Does bad code really teach you to write good code?
by tcf03 (Deacon) on Jun 17, 2005 at 15:56 UTC
|
| [reply] [d/l] [select] |
Re: Does bad code really teach you to write good code?
by TedPride (Priest) on Jun 17, 2005 at 17:55 UTC
|
You can't fully understand and appreciate good code without having written bad code first. Your mind only remembers what is useful to you, and an answer to a problem that you haven't run into yet isn't going to stay with you long. I often write answers to SoPW questions that have been answered already so I can compare my code to the posted solutions. I just have to be careful not to post my code unless it will add to the discussion.
Even better than reading good code, however, is getting comments back on your own code, bad or otherwise. There's almost always a simpler, easier, more efficient way to solve a particular problem. Whenever possible without being annoying, submit your code for review. New SoPW questions are good for this, once you get past the basic newbie barriers of learning how to use strict, use warnings, use CGI (and other basic modules that everyone should use in the proper situations, like Digest::MD5), and how to manage references and nested data structures. When I first joined PM, I didn't know a lot of this stuff, and I imagine I annoyed a lot of people by posting my solutions with global variables and subs for processing form data and so on. My algorithms were good, but my code was crap. | [reply] |
|
|
Unfortunately most of the code I write is confidential by contract :( I have started working on some projects on my own at home but they are far from ready for scrutiny. I do believe what you say is true that getting feedback is an important part of learning. I feel that discussion is one of the best things life has to offer and enjoy hearing from my peers.
| [reply] |