Actually we have coding style that forbids comments. The code is meant to be clear enough that it documents itself.
I agree with that actually - nothing worse than out-of-date zombie comments littering the code.
That’s just… Silly. What happens when you have a method that takes up 75 lines of code and isn’t easily deciphered? I always imagined comments would be abundant in proffesional code, but not as much in personal projects because you know what all your functions do. Huh.
If the method was very complex, it would probably be flagged in code review and broken down into simpler methods. And there would also be several test cases for the method, demonstrating exactly what the method is expected to do.
Wow, coding in a job sounds much more involved than I thought! Interesting, I might have to change my coding style around a little.
To answer the start of the thread. Coding errors happen all the time.
The worse ones I realized for me, are the ones that happened logically. Like forgetting to change a variable and wondering why your animations aren’t working. Also, checking to see why your sprite isn’t moving because you forgot to activate the listener. Usually my IDE would catch those simple syntax errors for me.
For documenting, I think it solely depends on the project. Even though it is great when projects can document themselves, it becomes a lot more challenging when you are writing for a large group. It also becomes difficult if you are working on games, as sometimes it is difficult to come up with one word for each logic action. If the project you are working on is international, writing comments can sometimes save a lot of grief since you can actually easily get the documentation to throw into a translator. I think it depends on the job.
Comments should not explain what the code does or how it does it.
That should be obvious enough from the code itself.
Comments are there to explain why the code does what it does.
You’re just very philosophical aren’t you?
That’s a good way of looking at it though, you shouldn’t need paragraphs of comments explaining what it is. That’s just a waste of space. But I hate getting undocumented code from other programmers and they expect me to be up to speed in less than two days. On the other hand, over documented code just means someone is bad at commenting and explaining.
Comments can be useful. About half a year ago I changed projects, I was the maintainer of the codebase and the one that was responsible for the code’s health. After the change, others took over.
A few months later a colleague came to me and was all like “Nice going with the comments ! You made everything so clear!”. My response was between the lines of “What’s with the sarcasm, if You have a problem, ask”
Turns out, he was being sincere. My comments helped and brought some clarity, for me those comments were well worth it.
Flip that around: USEFUL comments are a good thing, not comments in general. Self-documenting code should still be the priority though.
I recently read somewhere that the hardest part of being a programmer is naming things. I called bullshit until I realized I spent 15 minutes trying to come up with a better name for “downsampledDominantMotionVectorBuffer”. I ended up with “downsampledDMVBuffer” and a comment explaining what “DMV” stood for. +1 point to anyone who can figure out what I’m working on.
Either motion blur or something to do with OpenCL and Motion Estimation Extensions. Really I just did a little googling.
Naming things is the worst, I used to end up with 25 letter variable names, and they were a pain in the ass until I realized my IDE had a variable name auto completion feature.
When my variables names get longer than 10 characters I have a look at them and try to find an abbreviation.
Horrible class name, but even more horrible variable name…
Are you saying he shuold have done the full
AudioFileFormatCheckerByJavaDefaultSoundLoading audioFileFormatCheckerByJavaDefaultSoundLoading;
instead of the abbreviated version?
“ByJavaDefaultSoundLoading” is completely redundant. What the hell is an audio file format checker? Why isn’t this integrated into the sound class or the sound loader? Besides, a checker shouldn’t even require any persistent state, so just make it a static function. That name is so packed with wrongness it’s almost underflowing.
I don’t know how some people can look at variable names like that and not just laugh at themselves and then instantly delete it. Nothing needs to be that descriptive, and it probably is the exact opposite of useful.
“There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.”
And I was like “Haha, what a funny coincidence; he said ‘two hard things’ but he was off by one”…
[quote=“theagentd,post:17,topic:45270”]
That’s definitely the case for me. I’ve been demotivated for a long time until a couple of days ago. I started writing of some kind of first classes for games (in scala), but it became boring or similar pretty early. It felt like writing down stuff you’ve already did too often. At first I thought it was because I was too used to developing games, but all other attempts failed as well…
Now a couple of days ago I revisited haskell (you might know I’m interested in that 
), and haskell was a real challenge to me. I took a look at Frag (a from-scratch haskell implementation of Quake III, written using something called Functional reactive programming), which gave me new motivation.
Finally I’ve got a little, white rectangle drawn, which follows the mouse and becomes big, while holding ‘shift’ 
// – Non-Java / Haskell section – //
I had made some funny stupid mistake while in that process, too. It’s not that something didn’t work, it’s just that I did something sooooooo much more complicated, it’s cracy
So what I was trying to do is writing a Signal Function in Yampa, that took as input whether the user pressed the ‘Close’ button on the window and should output a boolean determining, whether the ‘reactimate’ process should stop (i.e. the process should be stopped).
What I did was this:
{-# LANGUAGE Arrows -#}
data Input = Input { window :: WindowInput }
data WindowInput = WindowInput { closed :: Bool }
mainSF :: SF Input Bool
mainSF = switch whenCloseSF (const $ constant True)
whenCloseSF :: SF Input ((), Event ())
whenCloseSF = proc input -> do
pressedClose <- edge -< ((closed . window) input)
returnA -< ((), pressedClose `tag` ())
The simple version was this one:
mainSF :: SF Input Bool
mainSF = arr (closed . window)
Well… I learned a lot while doing the other version
Btw, both being demotivated and having switched to scala and then to haskell is the reason for me not to contribute too much to this forum anymore 
Still love the people here, though! 