Ask Slashdot: Getting Feedback On Programming? 196
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 (Score:5, Insightful)
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.
Re:Contribute to open source projects (Score:5, Interesting)
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.
In open source projects, there are problems of all scales. As a newbie, and unfamiliar with the code base, you will only be able to tackle few bugs. So choose a project and a bug you are interested in, and get into it. Bug after bug, you will be able to tackle bigger problems, improving your programming skills (reading code, design, implementation, testing, communication, etc.).
Don't get bummed if your first code contribution doesn't work out or a interesting project isn't communicating with you. Just move on or do your own thing if you really think it is worth it.
Re:Contribute to open source projects (Score:5, Informative)
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.
Writing your own code is invaluable, but when you are just starting out it helps not only to contribute to open source projects, but also to read, read, read. I recommend going through some interesting projects and then forming an opinion about which ones have the best code. Don't just look at it superficially; try to form opinions on specific practices, idioms and designs. Then choose a project to work on and try to follow those ideas. From that point the feedback will be more valuable.
One of the things that Kent Beck said one time (possibly in an interview with Floss Weekly; I can't remember) was that his level really improved when he sat down and really thought about what he was doing. He just kept writing things over and over again until he could say exactly why he did everything. IIRC, he wrote down all his ideas and put it in a book on Smalltalk coding practices (which I haven't read yet...) I've been trying to do the same thing lately and it is really beneficial. Forming your own ideas and *then* getting feedback seems to be more productive than writing "just to make it work" and getting feedback.
Just be open minded when you think you have it all sorted out, but someone else thinks your ideas suck ;-)
Re: (Score:3)
Coding dojos do something similar.
Re: (Score:2)
True, but those who want to write do something else
Yes, we post on Slashdot. After being savaged by grammar nazis and had our arguments ripped to shreds, while getting into the habit of writing several thousand words a day with no proof reading, writing a book seems pretty easy in comparison...
Re: (Score:2)
Try coding for OSS (Score:3, Informative)
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.
Re:Try coding for OSS (Score:5, Insightful)
It's going to be nigh impossible to get anyone to review your work code, even though they should.
This is unfortunately all too true in most cases. Most organizations do not understand the benefit of rigorous code reviews. If they review code at all, they often only look to see if there are bugs, or if (usually fairly arbitrary) coding standards are followed. I've been lucky enough to work on a few teams with brutally honest reviews. It can be intimidating, but in the end it is incredibly useful for developing yourself. Things like pair programming can also be very useful in this regard.
One of the things that always bugged me as a programmer was that never once in 20 years did anyone ever evaluate my performance on the basis of the quality of my code. In fact, it was unbelievably rare when the person who evaluated my performance ever even looked at my code. Many of my immediate superiors would not have had the ability to judge one way or another, but even then they never bothered to ask my peers to look at my code and comment.
For some reason, I often think about programming teams as if they were sports teams. The way most teams are run, you have a manager who knows little about the game you are trying to play and never watches a game. There are no coaches. You performance is loosely evaluated on whether or not your team wins games, but even then the manager usually tries to make it appear that the team won every game whether they did or not. When they try to get new players, they don't bother looking at the success of the player on their previous teams, or even watch them play. At most they set up some artificial 5 minute drill and evaluate that, but usually they base their decisions on a feel-good interview.
It's quite literally crazy IMHO. In the case of sports it is obvious that this isn't going to work. I'm not sure why it isn't obvious for programming teams.
Re:Try coding for OSS (Score:5, Interesting)
One of the things that always bugged me as a programmer was that never once in 20 years did anyone ever evaluate my performance on the basis of the quality of my code. In fact, it was unbelievably rare when the person who evaluated my performance ever even looked at my code. Many of my immediate superiors would not have had the ability to judge one way or another, but even then they never bothered to ask my peers to look at my code and comment.
It's so hard to do this. I had one coworker who wrote basically unreadable code, that was riddled with bugs. He knew that he had problems, but wasn't sure what. I tried to suggest a few things, but he was really defensive. He disagreed with me, and argued every step of the way. So I took a slow approach, and gave him extremely mild suggestions over time. Eventually he started to improve, but then he quit.
It is really hard to give programmers coding advice, because usually they are defensive, and will defend their code. On the other hand, I did have one coworker who actually asked for advice from time to time, and when I saw places he could improve, I emailed them to him.
Re:Try coding for OSS (Score:5, Insightful)
Unprofessional programmers are defensive. A good programmer will listen and learn when he can.
Re: (Score:2)
One of the things that always bugged me as a programmer was that never once in 20 years did anyone ever evaluate my performance on the basis of the quality of my code. In fact, it was unbelievably rare when the person who evaluated my performance ever even looked at my code. Many of my immediate superiors would not have had the ability to judge one way or another, but even then they never bothered to ask my peers to look at my code and comment.
It's so hard to do this. I had one coworker who wrote basically unreadable code, that was riddled with bugs. He knew that he had problems, but wasn't sure what. I tried to suggest a few things, but he was really defensive. He disagreed with me, and argued every step of the way. So I took a slow approach, and gave him extremely mild suggestions over time. Eventually he started to improve, but then he quit. It is really hard to give programmers coding advice, because usually they are defensive, and will defend their code. On the other hand, I did have one coworker who actually asked for advice from time to time, and when I saw places he could improve, I emailed them to him.
He quit because after a lot of work he was finally able to realize just how bad he was. [wikipedia.org]
This guy was unusual because that almost never happens.
Re: (Score:2)
Re: (Score:2)
Codebases are of vast different quality. For example,
mplayer - not very nice code base - something I would not want to immitate. Not for beginners.
Qt - fairy good, sometimes rushed. Reasonaly good architecture. Most recommended out of these 3 for beginners - plenty of documentation.
Linux - mostly top-notch, especially the core stuff. Recommended for experts - code is documentation.
Re:Try coding for OSS (Score:5, Insightful)
If you really want comments on your work you need to find someone with experience that is willing to give up some time to mentor/review your work. "Sometimes" you may even find the odd lecturer that has some industry experience, though they seem to be pretty rare and many have a highly inflated (and unexplanable) opinion of there own work. Or perhaps look at some of the online programming forums, many people want peer reviews and swapping code for review not only gets your own work reviewed but gives you exposure to what others produce.
Re:Try coding for OSS (Score:5, Interesting)
If you really want comments on your work you need to find someone with experience that is willing to give up some time to mentor/review your work. "Sometimes" you may even find the odd lecturer that has some industry experience, though they seem to be pretty rare and many have a highly inflated (and unexplanable) opinion of there own work. Or perhaps look at some of the online programming forums, many people want peer reviews and swapping code for review not only gets your own work reviewed but gives you exposure to what others produce.
This would be great, if you can make it happen. In the world I live in, the number of people available to think about anything - programming, or otherwise, decreases like an e^(-x) curve, thousands will give you the 30 seconds it takes to whip off a quick sound-bite of "what they think" after skimming over your question, hundreds will give an extra 60 seconds to actually read the question skim the reference material and cogitate about what you might want to hear rather than what they want to say, tens might take the time to look at a one page program and think about what you're trying to do, by the time you get to 10 pages of code you'll be lucky to find one (experienced, knowledgeable) person who will actually do it. If he's been programming for long, I assume his projects are getting up there in size.
At least the arrogant pricks defending their OSS fiefdoms will read your code most of the time, if you've submitted it in the proper form. Sure, they'll throw it back in your face if you've used superfluous parenthesis or non-style compliant indenting without even checking to see if it works; but, occasionally, they really do want that bug fixed and they will give you some substantial feedback about your methods. And, if you keep submitting to different projects long enough, you'll eventually find a reviewer who isn't an arrogant prick. The guys at Qt were rather nice about it when they said "oh, nice fix, but we're deprecating that whole branch for version 5, so we're not going to take the time to regression test your code and just leave the 4.x trunk broken for every Intel laptop graphics chipset made in 2008-2010, after all, it's actually Intel's drivers that are buggy."
Re:Try coding for OSS (Score:5, Funny)
Your "idea" doesn't work within his original request. Is that all you fucking retards know is to caw on about open source? A bunch of fucking jokers. If you can't offer up advice to adhere to the original request then shut your fucking ass. Fuck you and fuck your open source. Fucking retarded bitch ass cunt.
Please don't sugar coat it. Tell us how you really feel.
Re: (Score:3, Insightful)
The quality of open source is usually pretty high, and there is a ton to choose from - from trivial to major projects. Telling someone to look at properietary or closed source code is likely to lead to a dead end.
Contributing to open source is a different issue: there are usually barriers to entry and a degree of "cliqueness", but thats understandable. Open source projects provides a good vehicle for understanding how groups of people interact. Sometimes its not just about coding and algorithms, but also ab
Re:Try coding for OSS (Score:4, Insightful)
On the Internet, nobody may know you're a dog, but everybody knows you're an asshole.
Comment removed (Score:5, Funny)
Re:Post it (Score:4, Interesting)
Seriously, though, the problem is that so, so much about programming structure and form is debatable. Since he's a student, he probably does have some obvious rookie mistakes that can be corrected, but he'll still get told many absolutes that are really not at all absolute among good programmers. Some people will correct you for having variable names over, say, 10 characters; others will tell you NEVER use a goto; others will give you a very hard limit on the number of lines any method should be -- on /., I've seen someone claim no more than 10, which is ludicrous to me. A result of all this is that you should ask for advice but judge the reasoning of the advice rather than accepting it blindly (and re-judge it again when you have more experience), and doing that while also pleasing the person giving you advice can be a tricky social situation.
Re: (Score:2)
Some people will correct you for having variable names over, say, 10 characters
Variable length limits are important if you are using a language like C, where the compiler is not required by the spec to use more than the first 31 characters of an external identifier (which is great for obfuscating code with old compilers, where you can use multiple names to refer to the same identifier). This limit exists for some old binary formats that placed a hard limit on symbol table entries. If you are targeting an embedded system, long names for externals can still chew up a lot of space in
Re: (Score:2)
... others will tell you NEVER use a goto
NOooo! That is the word the knights who say "Knuth" must never hear!
quite obvious (Score:1)
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.
Re: (Score:2)
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.
X is more difficult than the kernel, and probably more important too.
Re: (Score:2)
If dificulty of understanding code and getting it accepted is the metric, aim directly to Open SSH or Free BSD.
Re: (Score:2)
X is more difficult than the kernel, and probably more important too.
You gotta understand that with X, they have to be extremely careful what they accept, or they might end up modernizing the system. Nobody wants that.
dont worry so much (Score:5, Informative)
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.
Re:dont worry so much (Score:5, Insightful)
I recently worked on a pub website that needed to change to reflect the weather (they've got a big beer garden). My first stop was some code I'd written a couple of years back which parsed METAR data from airport weather stations - I'd already done most of the work I needed to do, but there were a couple of bits that I needed to add. Not wanting to use a bunch of (billable) time I had a look around and found a PEAR module that did much the same, plus a lot more. But it was pretty heavyweight for what I wanted, it was producing four dimensional arrays for example, when all I needed was $wind[speed], $wind[direction] and so on.
In the end it turned out to be far simpler to hand code my own, an entire PEAR module was replaced by 20 odd lines of code.
As I said at the start, I generally agree, it's important to be aware of resources like PEAR, CPAN and the like, but (especially when you're learning) you can progress by leaps and bounds by doing some things yourself. Plus sometimes there's a 5 minute solution compared with 20 minutes figuring out how Module-X works and how to integrate the results.
Re:dont worry so much (Score:4, Insightful)
1) to write, debug, and maintain your own code
vs 2) to understand, debug, and maintain (your integration with) someone else's code
The way to get good at estimating those things is to try it. Try integrating someone else's code, and try writing from scratch. After a while, you get a feel for how long each one will take.
Re:dont worry so much (Score:5, Insightful)
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.
It's hard to comment based solely on what you have written because I've never seen your code. But I have to question the level to which you are aspiring. There is a huge gulf in quality between code that works and code that is minimal and obvious. You say "maintainable, works, commented and capable". Unfortunately, that could describe code that is barely acceptable all the way up to excellent. I don't really know what you mean, so this might be superfluous to you.
Code that works and is understandable is the minimum quality of code that I think is acceptable. But when you are designing (or refactoring) code, the decisions you make can have a large impact on the rest of the system. Because I read a lot of the original papers on design patterns, I tend to think of code as having a shape (a lot of the earlier descriptions used this kind of metaphor). Code that has an appropriate shape fits nicely with the rest of the code. It has a minimal complexity (i.e., the code is no more complex than the problem it is trying to describe). It also doesn't complicate other code that needs to talk to it.
On the other hand, code with a shape that is not appropriate does not fit in. It introduces complexity based on its shape alone (independent of the problem it is trying to solve). Code that needs to talk to it often has to do something extra, or carry around some extra data to make it work. This creates an inappropriate shape for this new code. When you have one thing that doesn't fit well, it can have a ripple effect that increases complexity all through the code. Not only that, but there can be a multiplying effect. Each work-around that you introduce to accommodate inappropriate code causes more and more complexity.
When I look at large software projects, most of the complexity usually comes from dealing with other code rather than solving the problem. The more code you have, the more complex your system becomes. Most software projects actually solve simple problems, but are still very, very complex. You might think that there is nothing you can do about this, but if you look at system libraries they often simplify your life. This seems opposite to the "more code = more complexity" argument. The difference is that these system libraries usually have an appropriate shape for what they are doing.
Your advice is generally sound. Learning to use appropriate idioms, learning to use appropriate reuse libraries, writing understandable, working code is the basis of programming. But there is another level beyond this. Choosing appropriate code shapes, keeping complexity to a minimum, understanding trade-offs of coupling and cohesion -- This is quite hard and requires a fair amount of practice. Excellent code is not just maintainable and documented, but also minimal and obvious. When other code interfaces with excellent code, it is easy to do so and it introduces a minimum of extra complexity.
IMHO, you should strive for this. If you think that you already accomplish this without thinking about it, then I invite you to look again. I suspect you may be overlooking something.
Re: (Score:2)
Not sure you will see this, but I wanted to say that I looked at your code. I didn't spend nearly enough time on it to make a fair comment on it, but writing open source code is a great way to get feedback on your code. I definitely get the same feeling on my own project (http://jldrill.rubyforge.org/) with respect to "perfect is the enemy of new features". Often I need a feature and I simply don't have enough time to implement it well. Those kinds of short term and long term tradeoffs are tricky. The
Re: (Score:2)
as long as your code is maintainable, works, commented, and capable, you're doing a good job
I strongly disagree. Anyone in a CS program can debug code that doesn't work, or refactor code that looks bad. The benefit of experience is being able to anticipate what might go wrong in the future or under different conditions. It's about knowing what to look out for before it becomes a problem.
I'm sure all the newbie coders whose work adorns The Daily WTF thought their code was maintainable and functional, but it shows up on TDWTF because it broke when conditions changed and someone had to go fix it.
Re: (Score:3)
Re: (Score:2)
Somehow my adviser doesn't understand why changing the specs to a non-standard data format would be upsetting
Re: (Score:2)
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 aca
It's all in the comments... (Score:4, Insightful)
Comments mean your code is BAD (Score:2)
Re:Comments mean your code is BAD (Score:4, Insightful)
For some reason people on slashdot are super anti anyone that says comments are bad
We are, because it's a stupid opinion to hold. Comments are not bad. Redundant comments are bad. There is a really good, simple, way of judging the quality of a codebase: Picking a random function, how much more code do I need to read before I understand what this function is doing and why it's working that way? Clearly named functions and variables go a long way towards explaining what the code is doing, but not necessarily why. Doc comments mean that you don't need to read any of the other functions that are called, just their documentation.
Comments are also invaluable when the code is buggy. They tell you what the author of the code was thinking and therefore what they intended to write, which makes fixing the code much easier.
I've had to maintain code written by people who think comments are bad. In general, I would consider removing their keyboards a good way of improving overall code quality.
Re: (Score:2)
Re: (Score:2)
It is obvious you've never spent much time writing nor reading heavily optimized code, such as loop unrolling, removing branching, NOR fixing bugs. WRT the later a proper bugfix will contain a comment to the bugzilla number AND make a note about other potential issues / work arounds, test cases, edge cases, design flaws, etc.
Sometimes you also deal with code because the original programmer couldn't spend the time to properly name things (either function and/or variables), and only provides a few comments (
Re: (Score:2)
I don't understand this can you explain?
Re: (Score:2)
Whoops, look like I didn't properly format my html code.
Should be:
int i = *(int*) & x;
and
x = *(float*) & i;
Thus, the proper code should be:
float rsqrtf( float x)
{
float xhalf = 0.5f*x;
int i = *(int*) & x;
i = 0x5F375A86 - (i >> 1);
x = *(float*) & i;
x = x*(1.5f - xhalf*x*x);
return x;
}
Re: (Score:2)
Re: (Score:2)
It has comments so that when I read this code in say 6 months time I can still understand it.
Exactly - comments are messages to Future You.
How many times have you looked at your old code and said "WTF was I thinking when I wrote this?" Comments are there so you can answer that question. You may have done something dodgy or non-intuitive because you didn't know any better at the time, but on the other hand you may have done it for a very good reason.
I often write comments BEFORE I write the code, especially for smaller projects - the comments are the design document.
Re: (Score:2)
> If you have to write comments, your code is not readable nor understandable by another person.
That's nonsense.
_Proper_ commenting tells _why_ you did something. I want to know _how_ you did something I can [usually] read the code.
i.e.
* Did you work-around an existing design flaw that would be too big to fix?
* Was this a result of fixing another bug that exposed a new issue?
* Is the code doing something tricky / non-obvious?
* It also doesn't hurt to give a -reference- fo
Learn from others (Score:4, Insightful)
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.
Re: (Score:2)
Is your code "clever"? Then its wrong.
No one ever thinks their own code is clever. Other people's code is clever.
Re: (Score:2)
Is your code "clever"? Then its wrong.
No one ever thinks their own code is clever. Other people's code is clever.
No humble person thinks their code is clever.
Re: (Score:2)
Nah, you can learn from yourself.
Guaranteed way to improve your programs ... (Score:5, Insightful)
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.
Document with care (Score:2, Interesting)
Re: (Score:3, Insightful)
Too much documentation in the code renders it harder to read.
Only if you're doing it wrong. If you're doing it right, you won't be adding too much. It just won't happen.
The documentation will eventually become wrong because people change the code but do not then fix the documentation.
Those people should be fired. Preferably out of a cannon.
Man pages - yes
Documentation at the beginning of the file telling how to use it - yes
Those are okay.
Documentation within the code - mostly no - learn to write self documenting code.
This is absolutely wrong and inept. Comments are not for telling what the code does; they tell why it does it. You will never write good code until you purge yourself of the stupid that comes from this fundamental misunderstanding. Once you get this straightened out, you will never produce bad comments again.
Code Review Stack Exchange (Score:5, Informative)
You can try posting at least some of the code here:
http://codereview.stackexchange.com/
Time and features/improvements (Score:5, Insightful)
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.
Re: (Score:2)
Totally this!
I'll also add that when you find something that you later decide was written poorly, or is unmaintainable .. don't just bin it and move on.. really look at _why_ it's bad and how you got to that point. Sometimes you were just having a bad day, sometimes it was lack of understanding, but sometimes there are things in your design process that should be fixed. Is the problem due to something you could have foreseen? Why didn't you foresee it then! What can you do in the future so this won't happen
Walk-throughs (Score:1)
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.
Code Review Stack Exchange (Score:2, Informative)
There is a Stack Exchange site for this -- codereview.stackexchange.com [stackexchange.com]
Why so rigid? (Score:1)
Stick it in a box (Score:5, Insightful)
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.
Why not professors? (Score:2)
bit of reading (Score:2)
A good knowledge of design patterns is also very useful to cultivate. It makes problems easier to handle and solutions faster to devise.
get a summer internship (Score:2)
That's pretty much the way to both start networking, and get some feedback on your skills so you can improve.
Manager??? (Score:1)
Re: (Score:2)
Coop (Score:3)
Internal code review (Score:4, Insightful)
> 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."
Re: (Score:2)
Aside from asking your peers about whether they'd like to do peer reviews, you could also ask them how much experience they have. Just because someone is a student doesn't mean they have no programming experience.
I and two first-year friends of mine, for example, pretty much skipped our entire first year programming course except when exams were scheduled (with the blessings of the prof) because we'd all been programming machine language since we were 14-15 years old. By the time we hit university, we
Re: (Score:2)
I'll never forget wishing I could just walk out during the first 2-3 classes before I knew attendance wasn't mandatory. We sat through 30 MINUTES of some stupid humanoid trying badgering the prof as to when and where semi-colons were required. It was a brutal, brutal discussion. This individual was as dumb as the proverbial post, and could not grasp the basic idea that you needed a semi colon at the end of every statement except the last one in a code block. It was scary to think this individual might
Re: (Score:2)
Sorry for all the typos and grammar errors. I've got a migraine from hell and I'm having trouble seeing due to auras, so I'm pretty much touch-typing with my eyes closed.
Re: (Score:2)
This individual was as dumb as the proverbial post, and could not grasp the basic idea that you needed a semi colon at the end of every statement except the last one in a code block.
While it's true that the semicolon at the end of the final statement is unnecessary, it's also true that relying on the final statement you write to be, well, final is a really bad idea. Taking "advantage" of shortcuts like this is IMO a terrible programming practice and ought to be avoided. Honestly, sometimes it's easier to deal with out-and-out idiots like your classmate than "clever" programmers who write unmaintainable code full of traps for the person who inherits it.
Re: (Score:2)
Dude, we're not talking "C". We're talking a much, much older language called PL/C. If you put a semicolon at the end of every statement as you suggest, the compiler would barf.
Re: (Score:2)
Interact with people you respect (Score:4, Insightful)
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.
Start reading TheDailyWTF (Score:5, Insightful)
You should start reading TheDailyWTF [thedailywtf.com]. 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.
Find a mentor (Score:3)
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.
Re: (Score:2)
Stop caring. (Score:2)
Try this experiment (Score:4, Interesting)
(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.
Re: (Score:2)
Nobody needs to see comments like:
count++;
Yet without that kind of thing, it would be hard to reimplement the code from the comments alone. (Yes, if you have decent JavaDoc-style comme
Re: (Score:2)
Now you got what the GP meant.
Anyway, I don't know if I agree. Writting such kind of comments sometimes takes more time than writting the code, and the function name should be self explanatory most of the times. For an API, su
Document each entry point. It'll save your behind. (Score:2)
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.
Re: (Score:2)
/* Add one to the count */
Is useless, yes. But a comment explaining why isn't. Rationale is the thing missing from the code, and the thing you need most when it goes wrong. I don't need a comment as to what the code is doing, I need a comment as to what it's trying to achieve by doing what it's doing, and why.
And comments like "returns the current time in microseconds. Can never go backward" which was patently false can fuck right off! :-)
Re: (Score:2)
Re: (Score:3)
That depends what your goal is. If your goal is maintainable code, try deleting all the comments and ask people to tell you what the code does.
If they can't figure it out from the function and variable names, you need to stop using non-descriptive names like "i".
Look for professional meetups (Score:3)
imitate, assimilate, innovate. (Score:2)
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 b
Clean coding (Score:2, Interesting)
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
Two ways (Score:2)
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 t
Re: (Score:2)
To further simplify that code slightly, would
if(!var)
{
return;
}
doSomething();
be as equally valid as the latter example you showed?
You don't need reviews. (Score:3)
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.
My criteria... (Score:2)
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?
Program more (Score:2)
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.
What I do (Score:2)
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.
jm223 (Score:2)
Looked up jm223 [slashdot.org], 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 [slashdot.org], and based on his ID and a few comments it didn't seem [slashdot.org] like he is a student in search of a better form. [slashdot.org]
So it seems it could be a legitimate question.
The answer is to wor
stackoverflow (Score:2)
Have you tried posting this same question on stackoverflow.com?
One thing missing (Score:2)
I've give my pat advice (Score:3)
Trolling (Score:2)
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.
Negative is Positive (Score:2)
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
Test Driven Design (Score:2)
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 applicati