Slashdot Mirror
Ask Slashdot: Getting Feedback On Programming?
jm223 writes "I'm currently a student at a major university, where I do IT work for a fairly large student group. Most of my job involves programming, and so far everyone has been happy with my work. Since we're students, though, no one really has the experience to offer major advice or critiques, and I'm curious about how my coding measures up — and, of course, how I can make it better. CS professors can offer feedback about class projects, but my schoolwork often bears little resemblance to my other work. So, when you're programming without an experienced manager above you, how do you go about improving?"
Contribute to open source projects. You'll get plenty of feedback. Some of it might be quite, erm, 'robust', especially with certain projects. But it'll almost all be useful, and you'll be doing something worthwhile.
It's going to be nigh impossible to get anyone to review your work code, even though they should.
If you want some brutally honest critiques of your code, along with a healthy dose of nit-picking and "cultural bias", try writing for one of the major open source projects like FFmpeg, Gimp, KDE, Qt, etc.
Go ahead and post it. We'll offer plenty of........critique.
I object to power without constructive purpose. --Spock
get involved in a opensource project, the bigger the better, they often do QA reviews and force you to adhere to their guidelines and coding practices. Your ultimate test will be pushing something into kernel.org.
don't worrry so much about improving. you've probably been coding for 2 years or so (given you're in college) and have made amazing progress in those 2 years. the most important thing you can do is use existing libraries. when you reinvent the wheel, no one understands your code. when you use standard libraries, people still may not understand it, but it's going to be faster and more stable than equivalent code you wrote.
i've been coding for 8 years and as long as your code is maintainable, works, commented, and capable, you're doing a good job. also, for the love of god, don't hardcode your file paths or operating system. use a standard library, never do a system call. when you have do, error check it.
Ask somebody else to make changes to your code. You'll see plenty of arguments over pre-v-post incrementing or whatever, but the big thing is how well laid out and commented your code is...commercially, the chances of you being the only maintainer in perpetuity are practically nil, so it has to be readable to humans as well as computers. I'm well aware it's my major issue as a programmer, and one that I'm constantly working to improve.
Please consider this account deleted, I just can't be bothered with the spam anymore.
(open source contribution)
No matter how experienced a coder you are, you can only learn from others. Your code should meet the standards of others - eg look at equivalent source (open source projects). If your code is less than 1000 lines of code, then it can be considered "trivial" - by all means compare with other small projects. But look at 10,000-100k+ line projects and try to understand them. Now, look at your own code, and does it have the same modularity.
Is your code "clever"? Then its wrong. (Vast generalisation, apologies).
Learn the tools to debug and look at memory leaks, bad constructs, coverage etc. Try them - as many as possible, on your code.
And when you have done all of this, if you believe your code is good, then go back to the start of this subject and start again.
Additional points: measure your code quality after you have written 100-500 scripts/programs.
Those doing professional programming are never happy with their own code - they want to enhance and improve it continuously. Often, there is not the time to do this.
So, when you're programming without an experienced manager above you, how do you go about improving?"
Document them.
Write man(1) pages, describe the source code, include hints about WHY you chose the algorithms you used (and which techniques didn't work). Have a high-level document to say what a program is intended to do, in what environment, with what limitations and how the output should be used (this works for "batch" right through to web pages and apps). Show how it should be built, what test data you used, what the results were and how the tests were performed.
If nothing else, yo will learn that writing source code is the easiest 10% of being a professional programmer and that the other 90% is a hard, dull slog. However, it's that other 90% that separates the "play" programmers from the professionals.
politicians are like babies' nappies: they should both be changed regularly and for the same reasons
You can try posting at least some of the code here:
http://codereview.stackexchange.com/
Several ways: one is time. When you go back and look at a routine you haven't seen for six months, does it still look good? Or are you tempted to rip it apart and rewrite it? Did you put in adequate comments, so that you can remember necessary details after that length of time? Sure, coding styles change, but you shouldn't hate your old code.
Another is features. When you need to add/change/improve something, how easy is it? Do you need to rip apart old code, or can you just drop in something new with minimal changes? Does it work when the OS is updated?
Another is *user* feedback. If the project works, doesn't crash, and is easy to use, great. If you get questions about "how do I..." or "why does it..." then think about how your code could change to help the end user.
When I was working IT, we would schedule "walk-throughs", a meeting where other programmers would examine the code and offer suggestions. They never became "walk-ons". It was one of the best experiences I had. I gained respect for other's perceptiveness, creativity, and constructive criticism. Since everyone would eventually have a walk-through, we were professional and gentle, because we knew that we'd be in the hot seat sometime.
There is a Stack Exchange site for this -- codereview.stackexchange.com
The professors work for the university. If the dean tells them to help[ with non-academic projects, they should be willing to help. At least that's how it works in many workplaces.
Stick your code in a box, then forget about it for six months. Then come back, look at it, and figure out what parts make sense, and what parts don't make sense. And what parts you think are entirely horrible. Sometimes this works on a timescale much shorter, I've seen code I've written the day before, and thought, "what idiot wrote this??" Usually it's not that bad, though.
Three principles to follow, though, and if you get them, your code is gold. Make it:
- Work (if your code doesn't work, or is too buggy, nothing else matters, the code is useless).
- Readable (if no one else can read it, then your design principles won't matter because no one will figure them out).
- Flexible (if your code is flexible, then you can easily deal with changing requirements)
If you can get the first principle, make your code functional and mostly bug-free, then you're already in the top 50% of professional coders. If it's readable, you're in the top 1%. If it's also flexible on top of that, then you can write a book that people will admire for decades. Or a programming language. Sad but true.
"First they came for the slanderers and i said nothing."
Read Steve McConnell's "Code Complete 2", then do everything it says. It's like packing 5-10 years of experience into 1 book, and it is by far the best book on the subject.
http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670
Find and read bodies of code you really like. Compare it with your own work. If you want to sound like a rockstar you might not be able to get them to comment on your demo tape, but you can listen to thier work. Also when joining a team the first thing you should do is survey the scene and adapt.
Why can't you ask your professors to look at non classwork? I on more than on occasion went to my professors for non class related things. It really helped out in their classes, often times they were helpful due to the fact that I took interest outside of class in what they did. Open source is one way to have code review as posted by several other people. I find that my wife is not a good resource... She says things like "You did all that just for that, why not just use something thats already out there..." Work with upper and lower clansmen... While its true they may not have much more experience than you they do have different experience. They often times can see things different than you. Look for mentors in the industry or at work. Lots of people like to hear themselves talk so they are more than willing to ramble on to you.
If you haven't been taught, or feel you haven't been taught, enough about coding conventions (god knows I wasn't), try reading Clean Code by Robert Martin and also Refactoring by Martin Fowler.
A good knowledge of design patterns is also very useful to cultivate. It makes problems easier to handle and solutions faster to devise.
You could try posting on forrst to get constructive feedback.
https://forrst.com/
That's pretty much the way to both start networking, and get some feedback on your skills so you can improve.
"Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
See what makes other peoples code hideous and hard to read, go about properly formatting/commenting it as you are trying to understand it, and see if there are better ways to reorganize it and possibly refactor duplicate code with defines or templates; basically, spend a lot of time cleaning up crap code.
Experienced? Manger? Experienced Manager??????? Man, i am still waiting to see these two qualities in one man, but nevertheless, what this "manager" wants is to have the program at time, even if it is barely working......eventually...
Doesn't your university offer coops or internships? A few months of work in industry should help, even if the wage is shit.
Study hard and stay in school!
It's crap. If you continue on programming, come back in seceral years and you'll agree. Very few people write code in their first few years that they don't come back later with that opinion.
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
> Since we're students, though, no one really has the experience to offer major advice or critiques
See how the other students would feel about internal code or design reviews. They may or may not know what it is and they may take it the wrong way or not like the perceived criticism from peers, depends on your relationship with them.
About none of you having much experience -- maybe not, but part of college is wrestling with challenging questions that you don't know the answer to with people who don't know the answers either. If you're working for the college, even better. It may only lead to marginally better code, but hopefully you would all learn from each other. And it would look good on a resume to say you "improved coding standards and helped foster growth among colleagues by proposing and implementing a peer code review system."
You must know other students who code, trade reviews with friends.
One problem is that to do a decent job of reviewing code, you need to know what it is supposed to do. Practice writing requirements, program specifications, design documents or whatever fits the development style you are being taught, but you will probably have to explain a lot verbally to your friend unless you are amazing. Then he can give you a meaningful review and your users will have a more valuable product.
Doing the reviews of a friends code will teach you as much as getting yours reviewed does. You may be surprised at how much work it takes to make good suggestions for improvement. Also, there is a skill to offering criticism in a way that it will be accepted instead of generating anger.
There are development styles based on this practice, I hope you have good luck with it.
look at your code and honestly answer the question: can someone else understand this? refractor your code until you answer yes.
are there any duplicated code? I.e. cut and pasted or similar code? refractory till answer is no.
this will help you to improve. good luck!
You should start reading TheDailyWTF. If your code ends up there, you are doing something very, VERY wrong.
And if it doesn't, even better -- you can learn from others' mistakes.
There's no -1 for "I don't get it."
When I was having a particularly difficult time writing poetry, my professor told me: stop writing and read. Maybe it works for code, too.
I don't know about feedback per se, but for improving (and learning fun math along the way) try Project Euler. You'll be able to see how other people completed the same problems (and in different languages). It's not really about "what is the right way to do this" but "why is it done this way and not that way."
I learned a LOT by reading the MediaWiki and WordPress sources.
After you write a block of code, wait six months and then go back and review it. Chances are if you're improving and learning and gaining experience as you should be, it'll look terrible. You'll be able to critique your own work, learn from your mistakes and learn to avoid problems in the future.
Read code you wrote 6 months ago, a year ago and two years ago. If you don't see the difference you have not improved....
Outside of the intro classes (run by people usually just happy to get the paycheck) there are usually a few professors that actually do open source coding and/or research into programming... they seem to usually teach advanced coding/algorithms. Just network with them, find/ask for something you can maybe help them with and/or ask for suggestions in code that you've written.
Usually these people don't want to withhold knowledge, they wouldn't be in academia if they did, and as long as you aren't completely annoying about it they will most likely be happy to help you with whatever questions they can spare time for. They are there to teach you after-all.
The one regret I have in my college experience was that while I was better then most of my peers at stuff like coding the concepts discussed in class, it meant I wouldn't hit up professors in office hours like the suckup morons, that were in there every time they had office hours to suck up and try and get their programs done for them. Those same professors can be very helpful in recommending smart people later on, since most universities serve a regional community plus a lot of ex-students now in hiring positions looking for people from professors they stayed in contact with.
Re-read code you have previously written.
Start with code two years old, then a year old, then 6 months old. If you do not see an improvement you probably have not improved....
Find a mentor.
Join a local user group for the language/technology of your choice and make friends. Find one that is quite experienced and learn everything you can from them.
It doesnt matter. You wont be attached to any project long enough to make a difference. Keep your head down, and leave for 20% more pay in 2 years.
You make more money if you dont care. And you make less stress.
(1) Print out your code
(2) White out all the actual code, using Tipp-Ex, leaving just the comments visible
(3) Give the result to one of your fellow students, and ask him to rewrite your code in a different language.
If s/he fails, you didn't write enough comments.
In my area, I'm lucky that we have a large number of self-organizing developer groups. I found a bunch through meetup.com, and since I started going I've gotten much in the way of advice and encouragement, and picked up some insight. If you participate, don't just go and hang out -- put together presentations, and ask the audience for their thoughts. Probably lurk a while before doing that, but once you get the flavor of how they are run, put something together that you feel strong at, and present on it.
You see? You see? Your stupid minds! Stupid! Stupid!
We have a saying in bioinformatics: "sadly, that's typical of academic software." It means that the standards the submitter is coding to depend on what field he or she goes into; since we don't know, we can't really say!
Bio questions? Ask me to start a Q&A journal. Computer analogies available for most topics!
There's a lot of people on http://codereview.stackexchange.com/ that are happy to critique your code.
I'm certain Terry Clarke would never expect his advise to apply to something as humdrum as making a computer more useful; but this is the mantra of all artistic endeavours.
If you can find talented people to work with, so much the better. Either way read! Read good code. Read bad code. Learn to tell the difference. Open source is a treasure trove; it covers the range. Closed source isn't any better; in fact it is often 'secret' because its embarrassing.
Read some books on the topic. Not algorithm books - although you should read those too - but "Elements of Programming Style", "Software Tools", "Programming Pearls" ( the latter has nothing to do with that baroque version of awk, btw). These books focus on developing the craft.
"So, when you're programming without an experienced manager above you, how do you go about improving?" You dont, you either do jackshit, or change jobs.
Post to LKML.
The most useful thing that I've recently discovered in my 3 years of professional programming is "Clean Code" by Robert C. Martin. It covers most of the lessons that I've learnt the hard way.
The things that don't necessarily seem important when you're striving to get something working are usually the things that make a difference. Naming of classes, methods and attributes so that code describes what it's doing, keeping your in-code documentation up to date so it doesn't lie and adhering to SOLID principles (http://en.wikipedia.org/wiki/SOLID)
I'd thorougly urge you to read it. My colleagues (whom I respect greatly) have also recommended "The Practice of Programming" by Kernighan and Pike, that's probably also worth a look too.
One of the best ways to measure the quality of your code is to run it. This might sound obvious, but in a corporate environment there is a lot of pressure to develop software quickly. If you spend a lot of time making your code perfect to read, and extend, you may not be making the best use of your time.
The iterative development methodology is a good way to develop software, I feel. You write enough to get your software working, and deploy it to be tested as soon as possible. If it works, then you are doing a good job. If it doesn't you still have time to improve it. You will need to monitor the performance of your code when it is running, and make adjustments, if it's not meeting your expectations though.
Next time you go to write a similar functionality, you will know from experience what worked, and what didn't.
and doesn't crash randomly while doing it, I am sorry to say you will be ahead of almost everyone these days, proprietary and open source alike. It really pains me that computers seem to becoming slower and less stable, even as hardware becomes faster and more resiliant.
Look for a static analysis tool for the language you are using. That should give you plenty of feedback that is generally accepted among veteran software developers.
Let me save you alot of time. Your code is shit. Does it work? If so its passable shit. Does it make us money? If so, its good shit.
I am a badass coder and here is some of my awesome code from my login page in php 4 that is super secure
$query_login="select * FROM user"; //$login_check = mysql_num_rows($result_login);
$result_login = mysql_query($query_login) or die("Your passwrod is might be bad I think");
while($row=mysql_fetch_array($result_login))
{
$username=$row["username"];
if ($username==$username1)
{
echo "";
echo "window.location.href='login_error.php?rec=qq';";
echo "";
exit;
}
}
http://saveie6.com/
Writting such kind of comments sometimes takes more time than writting the code
But it can save your behind when you try to use code that you had written months ago. Documenting each method's pre- and post-conditions has saved mine several times. It may take more time than writing the code, but it takes less time than trying to troubleshoot why it's not doing what you expect and ending up discovering that the caller had not met a pre-condition.
Certifications, such as Oracle Certified Professional Java Programmer, aren't extremely popular, but studying OCPJP (then SCJP) forced me to learn a lot of bizarre intricacies of Java we glossed over in college (i.e. { byte a, b; a = b = 1; a = b + a; } fails to compile because + returns an int, so you need a cast a = (byte) b + a;).
I learned the most just by reading the code of people who are good coders. Especially if they're the type to put good comments in.
There are two ways to improve your coding that I know of, that can be done without someone else's input.
1.) Download code from the many online repositories, and study it. More experienced programmers have interesting tricks that help make your code both better, and more readable. For instance:
When I was a novice programmer, I would wrap entire statements in an if{} like:
if(var == true) {
doSomething();
}
which at first seems ok, until you run into bigger blocks of code. By the time you get to:
if(var == true) {
doSomething();
doSomething2();
doSomething3();
doSomething4();
doSomething5();
doSomething6();
doSomething7();
doSomething8();
}
you start to lose track of the trailing curly bracket.
After studying some code, I realize it is simpler to do this:
if(var == false) {
return;
}
doSomething();
where you find the conditions that would not trigger a block of code to run, and return early.
It makes the code so much easier to work with.
Additionally, if you are dealing with multiple errors, such as when you are dealing with users entering information into a database app, it's easier to just declare a more global string, append the errors to it (when validating), then check if the string is empty before sending the data to the database (if it's not empty, just display the string in a simple textbox at the top, with bold red font).
2.) Read books on the language / books containing good code. I think O'Reilly has a book called "Beautiful Code" which may help you there.
Since I program primarily in a MS environment, it has helped me to realize, after dealing with their APIs and what not for quite some time, that you need to balance between abstraction and pragmatism. Too much abstraction, as I've encountered in a Java environment, and you are chasing methods, constants, and fields all over the place. It can take hours to understand some piece of code with one too many layers of abstraction. On the other hand, not enough abstraction results in VBish code, with God-functions, which are also a headache. You want to segment your code so that you can get work done, and still be able to understand what you are doing without having to read the comments.To that end, think of good, but relatively short, variable and method names. Do not be afraid to give a variable a lengthier, but descriptive name. In today's day and age, you don't need to save disk space by sacrificing readability.
I am John Hurt.
Oh, maybe you wanted constructive feedback... ?
> When asked this question, I often think, "How do aspiring writers learn their craft?"
> People who study English read ridiculous numbers of books.
> This gives them a base to start from when they are writing.
True, but those who want to write do something else. They get together in small "critique groups" at their favorite coffee shop and discuss each other's work. I've never tried this with code, but with a couple of people of comparable but qualitatively different skills, I think it would be an interesting approach.
You just need to maintain/extend the same piece of code for 10+ years. That means calls at 3AM when it doesn't work. It also means having assorted 3rd parties come in and extend pieces of functionality on a regular basis and then leave.
That will teach you more about code maintainability and stability than letting a bunch of self righteous, clever idiots, "review" your code.
Of course, in the meantime... stick to the basics, clarity, consistency, and simplicity. Also, read a lot of other peoples code, you will discover what you like about their code, as well as what you dislike. Then don't write code like the stuff you find hard to understand. One of the big problems with software is that the KISS principle should reign supreme, but everyone thinks they are the next Mozart, and Einstein rolled into one. Rather than building the next Eiffel tower they end up creating the next Rube Goldberg contraption.
One of the best guiding principles I use (been writing code for over 15 years) is to think of the code like a Japanese haiku...less is more. Experienced programmers, especially ones who've had to work on big projects through several iterations and revisions, know that the more code you write, the more you have to maintain. This means making the lines code you have to write really count. Be succinct, avoid repetition, and have the code get to the point of what is trying to do. Use modular practices not only for re-use but to make clear the intent of the code. Above all else, remember that complex problems do not require equally complex code. There is a real art, almost Zen like, in rendering complex problem into understandable code. Computers never get confused but programmers can, so it is vital that you maintain intellectual control over what you are building.
Is the problem broken down into high level pieces you can quickly describe?
Is what any given snippet of code does and why easily understandable little to no searching?
Are there tests in place to validate the program's behavior?
Are there clear boundary lines that prevent erroneous input, error appropriately and minimize corner cases you have to manage?
Are all side effects cleanly sandboxed and limited to what is necessary to solve the problem?
Has repetition been avoided?
Have standard approaches and standard libraries been used whenever possible?
At the end of the day, is this something you feel good about having done and good about someone else inheriting?
My criteria for software:
Is it correct?
Is it performant (enough)?
Was it produced in a timely manner?
Can you or someone else go back in 6-12 months and understand it well enough to extend/fix it?
Awesome furniture, accessories and cabinetry in Santa Rosa, CA: http://humanity-home.com/
The best way to improve your code is to not allow yourself to write comments.
Programming is little more than staring at the computer and telling it that it's not good enough. If you can tell the machine, you can tell yourself. Just don't stop. It's all really easy, just keep going.
Your CS professors are there for more than school-related work. If you bring them a project that you've been working on they'll be thrilled to offer you critique on every aspect of the project. You may want to take your work to several different professors to get different opinions, too.
They're a good resource and they can mentor you in more than writing yet another sorting algorithm.
As a self taught guy, people won't code review for free. People may use it, but they won't review it. The only time that people will review your code is if a bug through use is found, or they are trying to learn from it. After having my work taken and used over the years, I just tend to follow the silence is golden rule. And FYI, professors (at-least at my public state university) aren't there to do code review, and the TA graders are often underpaid and under qualified. They are there to check a box to make sure you did the assignment/project. Joining an OSS effort can be an inadvertent source of code review, but this often comes in the form of competing designs and if you're lucky, actual patches to your code. As an example, If my code was understood to the point that someone was able to write a patch, I would consider this an affirmative plus.
I've been a professional for a few years now, so I work with other people and we work in the same code framework. Code reviews with others are okay, but I think your best critic will be yourself. Go over your old stuff that you don't remember well, and ask yourself "Does this suck?". It probably does. Fix it.
A programmer is never happy and never considers anything a finished product. Everything can be improved. Also, go to The Daily WTF and make sure you don't do those things.
Looked up jm223, because combined with the fact it was the first comment by him, it seemed to be a strange nick, a type of a nick that is used by many local trolls, when they are banned, they take the same base nick and add some numbers to it. However there is no 'jm220' , there is no 'jm100' but there is this character, just jm UID 18663, and based on his ID and a few comments it didn't seem like he is a student in search of a better form.
So it seems it could be a legitimate question.
The answer is to work with people who are better than you and learn from them, you need to observe them work or at the minimum you need to look at their products and learn by reading, this is the only true answer.
The best option is of-course to learn by working with somebody like that and learn by doing while working with them.
You can't handle the truth.
You'll then realize how foolish your desire to have your code reviewed really was. Hint: at Google, a punctuation mistake in a comment is a valid reason to reject a changelist.
Bioinformatics software is horrible. I've written way too many data format converters/massagers for software that doesn't like to comply with standards. My adviser has changed up the specs on the software -which I've been coding over that last two years- to now ignore the data format standards in order to add a minor function.
Somehow my adviser doesn't understand why changing the specs to a non-standard data format would be upsetting
Have you tried posting this same question on stackoverflow.com?
For some reason people on slashdot are super anti anyone that says comments are bad. Even though comments are bad. They add extra junk to sift through and should be completely redundant if you are naming things properly. If you need a comment your functions and variables are not named well enough and don't explain what the code is doing. When your code isn't named well enough and you have comments when you do go to refactor or change things you have to change both the name of the function or variable and the comment, but you only change one and the code and comments become confusing. If you don't understand this through years of programming experience you can always read books. "Clean Code" by Robert C. Martin explains it quite well.
The Official Site of 1337 Pwnage
That problem is throughout academic software. The problem is that most of it is written by domain experts who had a few quarters of programming (often in fortran). They get the job done more or less, but naturally have no idea of good practices, maintainability, and such. Alas, going the other way around would also be problematic since you'd get an excellent programmer who will need a year or two to understand the problem. That could be an interesting specialization for a contract programmer except that academic software is written by grad students, not contracted professionals.
Test Driven Development will help you a lot on getting better abstractions, structures, etc. when developing software. Now you need a good understanding of unit testing.
Also, there are many tools which should help you on doing QA on your code. This tools allow you to configure different 'features' your code should follow for it to be valid.
Code review is a pain.
Go back and look at your code after several months, when it isn't fresh in your mind. Does the code look good? Is it easy to read? Is the complexity level low? Are the method/function names appropriate? Are comments needed to point out any information that may not be apparent?
But don't just do rework without a good reason and following proper processes to make changes. Fixing unbroken code on your spare time because you don't like it will interject problems you don't need. And finally, don't rewrite other peoples work because you don't like it. Review it with them and discuss it but rewriting other peoples work based on your opinion will make enemies and even worse.
At the very least, write your tests before you write your code. You'll be amazed by how much better the development experience can be.
Read lots of other people's code (look for the good and the bad, you'll see lots of the latter and can learn to avoid it).
Code in several languages. Java isn't enough to make someone a real programmer. Learn to script bash, ruby and python. Learn C. Learn one of the functional programming languages (Erlang, Haskell, Clojure) to see how differently some problems can be approached. Learn C.
Don't be afraid of the command line, too many professional programmers I work with are novices when it comes to doing things on the command line.
Beware of those who have objects comming out of their ears and love to overly complicate the most simple process.
While I agree with many of the preceding comments, particularly the ones regarding documenting your code, one thing I would add: Always take the time go back to your code and ask yourself how you could make it more compact and more efficient, both in execution and resource demands. As you realize new efficiencies, they will inform and optimize your thinking process.
Mostly because this is something basic you can do for yourself. Can you come back to your old code 6 months later figure out what it does without completely reverse engineering it? I've pointed this out before but I'll say it again. You probably threw away your code 5 seconds after it was graded, right? Well the first thing you'll learn if you go on to be a professional is that you or someone else will be coming back to that code to do fixes and add new features. Ok, it's one of my serious pet peeves is that programmers, codes, software engineers, or whatever you want to call them not writing code to be in any respects readable. So you come back to the code and you can't figure it out without wasting days completely reverse engineering it. (Which is frustrating as hell.) If you can learn to write readable code(so that you can come back some time afterwards and quickly pickup where you left off) you'll be way ahead of the game.(IE you'd be a better developer than most pro's. At least that's been my experience.)
Did you know 80 to 90% of the moderators on slashdot wouldn't recognize a troll even if one dragged them under a bridge.
Post your code and brag about how it's superior to everything else out there. This will enrage all the "someone is WRONG on the Internet" types and you'll get tons of feedback about your code's flaws.
This was also an effective strategy to get the attention of experts on Usenet groups.
The quality of programming has two major aspects. First, there are objective metrics which can be used to determine the quality of code. In the Java domain you might use Checkstyle to determine if your code complies to certain accepted standards. There are other tools which support style checking. They work on lines of code, length of lines and identifiers, number and style of methods and classes. Advanced tools also try to identify design patterns. If they were not covered in your studies you might look them up in your library or if you cannot find any book on that topic in your library use [http://en.wikipedia.org/wiki/Software_design_pattern] as a starting point.
Second, there is also an esthetic aspect in good programming. This aspect is merely subjective. However, certain properties as symmetry can also be measured. but it is more important to know them, then to be able to measure them. but there is more to esthetics than measurable qualities. Some people like functional programming. It has its advantages and together with object-oriented programming it can be very useful. However, other people think more in procedures, they most likely prefer imperative programming. Mixing both styles can cause unreadable code. As functional programming avoids states, imperative programming enforces states. While the imperative programming makes intensive use of side effects. Functional does not. So mixing is bad style. However, there might be situation where this is not avoidable or even the best solution.
There two aspects occur on every level of software development. There are elegant algorithms, which are esthetically pleasing and efficient. On the other end there are application designs or even deployment models which look well-formed and conceptually sound. to every level, there exists extensive literature and to become a good software designer and programmer you might consider learning all accepted patterns and style guide will improve your skills. Everything beyond that is subjective and only and opinion. Just like: is a Van Gogh better then a Da Vinci?
A good way to tell if somebody's code looks like line noise is to ask them if they have a Ph.D.
Evaluating code today is more complicated than it used to be.
When I started learning programming in the mid eighties, the OS and system libraries that your program used were documented in a book and didn't change often.
Even if you didn't own the book, the release cycle of the code your program depended on was stable enough that you could rely on it and it was produced by large companies that generally produced stable/reliable code.
Nowadays we have google and can find all sorts of useful libraries, the problem is that:
This whole problem is compounded if you deal with frameworks. A framework is a type of library that typically imposes some level of 'inversion of control' on your code.
In cases where the framework is mature and solving it's problem well, and is sufficiently extensible, this saves you a lot of work.
A bad framework though is worse than code you wrote from scratch, because you lack the control to make it do what you want.
I'd say that the most valuable skill today in programming is to get good at evaluating and integrating with outside frameworks.
In the area of Java/J2EE web development I find I have to revisit the 'framework' question every 18 months and see if it is really worth upgrading Hibernate/Spring/Spring Security and various other components of my project template.
Upgrading may allow me to obtain certain benefits and new features but also introduces the possibility of new bugs.
--
Can't buy what I want because it's free.
is an oxymoron
I have found that very effective ways to become a better programmer are:
1) Maintain other people's code for a couple of years, you will see/learn what are good coding techniques and what aren't, if you pay attention, I guarantee you. Learn to recognize good techniques.
2) Try modifying/updating/maintaining code you've written, after not having looked at it for a year or more. They see what you think of your coding style, documentation and comments in your own code.
3) Comment, comment, comment your code. BUT the comments shouldn't be about what the code does, that should be obvious, the comments should explain WHY the code is doing what it's doing. What was tried and didn't work, what worked and why...
4) Make your code no more complex than it needs to be. This sounds simple, but it's really not that easy to do. There are constant trade-offs to be made when designing/coding/maintaining software. The trade-off between time (amount of code to be written) and its short/long term benefit. In most cases I've encountered, this aspect ultimately determines if a project is successful or not (but only in the commercial world).
Most of the method mentioned above are quite useful.
Ask questions. One of the best questions I learned to ask at work was, "What are you working on?". Then following up. How does it work? What are the hard parts? Anything you might not know how to do easily are good things to ask about.
If you can form a group to do peer review that would be great. Reading others code will help you learn what is hard to read and maintain as well as good habits and good techniques. In a group, the more novice coders learn just as much from reviewing more experience coders as from being reviewed. More experienced coders still learn. I have been impressed to see how rapidly best habits propagate.
Reading general articles or specific examples are always good. Open source is fine but there are lots of source. blogs or tips on anything you find interesting will help move you forward.
The question raised in another comment was, "how do writers learn to write". One response is "by writing". Side projects can be great. Tackle somehting that you will want to maintain over time. Write a project from soup to nuts, and defintiely maintaining over time are great learning tools.
as you work, collect lists of everything you think went wrong in your programs and programming practices (both practical and academic). you will then be prepared to sit down with your notes from the last quarter and identify broader themes. once you can frame issues in common terms - e.g. your web API mangles UTF-8 input, or you find that you are creating new bugs at an unpleasant rate, or your users aren't understanding your documentation well - you can look up how others have addressed these problems. then the action items will become apparent (eliminate operations that assume input is 8859-1, or adopt a unit testing framework, or work with a technical writer to clarify the text).
Come on , mods! This was funny, if for no other reason the perfect use of "caw on"... bravo sir.
P.S. you're wrong.
In my organization (disclosure: big bank) we use a marvelous atlassian product, Crucible, for code reviews. It's wonderful. You use a browser to put out your review, choosing the contents from your check-ins into your SCM (Subversion and Git at least, that I know of). You and your colleagues can put comments, replies to comments, replies to replies, etc .. and directly into the source code (something link post-its). You can summarize with general comments as well. Keep track of who reviewed (and who didn't). It's a nice interface that keeps the whole team involved in "owning" the code and gives each individual the opportunity to make his "critiques", suggestions, rants, etc.
Unprofessional people are defensive. A good person will listen and learn when he can.
FTFY
And encyclopedias are bad too, because instead of getting quick overview on a subject and going on about my life, I should spend 10x the time and effort reading through all the available literature on a given subject and learn every detail about it, whether I needed all that information or not.
As long as it works, just fire it off and forget about it. If it sucks, that's a maintenance programmer's problem.
Quidquid latine dictum sit, altum sonatur.
Ask yourself - what is 'great' code. If you haven't seen 'great' code then you need to read more code. It exists. You will know it when you see it.
If you haven't already exposed yourself to languages that embrace re-factoring as a way of life you should. One of the best is Forth. Good Forth is like poetry. Chuck Moore has written several things about software and they are well worth consideration.
Good code I've read has usually got the following in common:
- It's correct - It does what it says it does and sounds like it does.
- It is side effect free.
- It has been re-factored extensively.
- It is as short as it can be without making it more difficult to understand or introducing structures which are fragile or do bad things if you don't use the correct magical incantations which may be non-obvious.
Here's a couple of concrete things you can do with your existing code:
Imagine you wrote a 1000 line program.
Ask yourself can this be a 999 line program? When you get to the 999 line program, ask the same question.
Eventually you will reach a point where you can't reduce the length of the program without making it less clear. At that point ask yourself, can I re-factor it in a larger sense to make it MORE clear while keeping it correct.
Ask yourself if each method, function, class does what it says it does, and sounds like it should do. Check the program is still correct. Is the program robust? How does the code behave when its inputs are changed. If it's production code that will get hammered on then maybe you should add a comment about the time and size complexity.
One of the worst places to find bad code is API's. Experienced programmers know it's truely difficult to write a good API for a non-trivial program that stands the test of time. A good API isn't just sticking a bunch of public methods like so many people think it is. Find an API that's stood the test of time. Read up on it. If the programmer has written about the design decisions then read up on them.
Finally, think critically about what you KNOW and don't KNOW. Learn something new. Don't just skim it, read it and study it till you grok it. It can be something others take for granted say floating point. Read up on floating point arithmetic. Read about its pitfalls. You'd be amazed how many people who say they are good programmers don't understand precision, accuracy or that floating point numbers are imprecise.
Don't become a Programner, you have too much inteligence. - Programmers' are just translaters. Use you knowledge and skills to define what you need and then get a code monkey to translate it for you
I've never had a competent manager that could review my code. Managers, specifically project managers, know jack about code. The only thing they know is schedules and the fact that we're running late (and that it's all your fault and not theirs for underestimating...).
I spent my first five years in software getting hold of the code of the world's most celebrated programmers (in my own field) and seeing if I could emulate them. That's great but not easy. My feeling these days is that the best thing you is swap code reviews. Get a friendly experienced programmer to code review your work. Return the favour.
I'd be happy to review your work & give you my thoughts. You may need to do the same back :) Steve ... sfkleach@gmail.com.
The Personal Software Process (PSP) is a structured software development process that is intended to help software engineers understand and improve their performance, by using a "disciplined, data-driven procedure".
It sounds a little esoteric for programmers who like to code and not collect any data, but in my experience, it works.
https://en.wikipedia.org/wiki/Personal_software_process
O this learning! What a thing it is - William Shakespeare
I can (and will) speak only for myself
However, I have the basic philosophy that negative feedback is what improves a product. Kudos feel good, but criticism is what I need to make whatever it is I do, better.
Feels worse, but the results are what I'm after.
Takes a lot of humility, and the ability to look past invective and puerile garbage, to unearth the truth.
Put your stuff out there. There's nothing that geeks like to do more than throw feces at each others' work. Some of that stuff will have merit. Be careful about what you dismiss. Also, be grateful for strokes and positive reinforcement, but also measure that against your own developing sense of aesthetics and style.
You will rapidly learn that there are dozens of ways to do things right. There's a ton of sacred cows and third rails in the IT world (A sacred cow is a concept that is so "holy," that it cannot be attacked, and a third rail is a concept that is so toxic that it should never be touched).
Most of these "hard and fast" rules come from singular events, or as a result of abuse by folks that don't know how to use the tools properly.
Take, for example, C++. There are folks that believe the language is The Manifestation Of All That Is Evil, but I make my living running a C++ shop. I get to hear all the ranting and raving about how I'm contributing to the downfall of civilization, yadda, yadda..
However, it is a very dangerous tool, in the hands of an idiot. Because lots of idiots have blown their legs off with C++, they declare that it is evil.
In some ways, they have a point. If you don't know what you're doing, you can make a fearsome mess with C++. If you decide to become a C++ programmer, then, PLEASE listen to all the negative feedback, and keep it in mind. Be careful in the use of things like multiple inheritance. The Design phase is critical. Far more so, for C++ than for languages like Objective-C.
Know your tools, and put your code out there. Do open source work. Make something that other folks would use. This will result in de facto code review.
"For every complex problem there is an answer that is clear, simple, and wrong."
-H. L. Mencken
Code Complete by Steve McConnell
Refactoring: Improving the Design of Existing Code by Kent Beck, Martin Fowler and Akira Hirasawa
Get a colleague to read books and then criticize each other's code.
It gets amazing results.
I had the same problem, no senior level programmers to teach the craft. We had once per week lunch meetings and had one programmer show his work, and the others criticize. Our code became much clearer and our bug counts went way down.
Good Luck!
Now is a good time to start good habits rather then developing bad coding habits.
Read up on test driven design.
The biggest fail of any developer is in thinking they should write more code then is required to solve a purpose. Many developers love to create grandiose architectures in order to solve simple problems, and every line of code you write (whether it is impeccable or absolute garbage) can result in a defect.
Test driven design changes your mindset from "Hey, lets dump a bunch of code into an application and eventually it will work." to "What are the requirements of this application".
You design unit tests according to the requirements of the application (and it forces you to identify exactly what the application should achieve). You design the unit tests to fail at first and then you write your code to make them pass successfully. By doing this you only write "enough" code to match the requirements of the application because you are only focused on making the unit tests pass. This avoids over-architecting and because your code is unit tested, adding new code in the future will ensure it is always self-reviewed because the tests will fail and you have to fix your code.
This is a hard concept to understand at first (and most developers will always baulk at the idea), but a very useful coding practice when you get the hang of it.
In the end, its not about reviewing lines of code and confirming that, yes, this is good code. Its about writing good applications that do what they are supposed to do with a minimum (or no) defects. This is a fundamental flaw of most code developers in assuming they have to write gobs of code and expect to be patted on the back because it looks nice or conforms to some coding standard; I have seen some beautifully written code that is full of defects, as well as have seen some of the worst looking code ever execute flawlessly.
Peer review does not prevent defects. Mostly what happens in a peer review is a bunch of nit-picking and a false sense of security when someone "more senior" signs off on a a code review. They want you to follow their coding "standards", make your code look like theirs. Bottom line is, if you write unit tests first and those unit test pass, then there is nothing a code reviewer can say negative about your code except to nit-pick, because the code simply "works", meets the expectations of the software requirements, and is protected from future defects because it is tested.
Test driven design is the only way I can see an individual developer writing good applications without having a mentor, it focuses on writing code that works, not about style or design.
I haven't thought of anything clever to put here, but then again most of you haven't either.