|
Haha... 25 years and 20,000km too far and too late
|
|
|
|
|
I personally like descriptive names. atoi is way less readable, than StringToInt, for example. But that's a library function (I'm working polyglot, but not everyone is), what about own functions?
When I write code, I like writing it in a way that makes clear what it does. Sure, I could litter it with comments, but too much of a good thing is real. So I have functions named DecodeL7 (with L standing for "layer" which, I admit, may be not explanatory enough). My variable to hold the L7 buffer is named accordingly, L7Buffer. Inside the DecodeL7 function, the variable name is just L7, it being a buffer is kinda obvious from context.
The example above however is a bad one. Calculation() does exactly 0 to tell the maintainer (who may be another person, or oneself in 10 years) what the code does, so it may just as well be DoIt() or frob() or just f(). With every modern programming environment supporting unicode, there's a plethora of one-letter identifiers. ä(µ) isn't readable though. At all. If it's not code I'm working on daily, I know I'll forget what it's doing after taking care of another product for a month.
As for my reading habits, I indeed parse whole words at once, both in code and in text.
As for useless code review comments, a co-worker of mine is the kind of guy saying, almost verbatim, "I've learned it that way half a century ago and I'll never learn anything ever again". Needless to say, his comments during code reviews are utter shite.
|
|
|
|
|
Agreed.
Can't stand them either.
Just let me do my job. You don't need to be included. Go away and do your job.
If you have a problem with my code, you are welcome to fix it on YOUR OWN time.
And FYI, I might have a problem with your code too, but I'm not arrogant/rude/petty/anal enough to tell you. I'm not here to look over your shoulder, you need to be able to work on your own.
If you are happy that the code works, the team are happy too.
That felt good.
|
|
|
|
|
Maybe you work for a code effort where you are the only coder who will ever touch your code. Great for you.
But if there's even a small chance your co-worker has to understand your code? Then it's not arrogant to expect it to make sense to a larger audience. It's common sense and good teamwork. I've been in this business a long damned time and I've seen what happens with and without reviews. I'll take the shop that does reviews, thanks.
I would be arrogant if I thought my code should be untouchable.
|
|
|
|
|
It's fine if someone doesn't have the confidence to write code without a supervisor. It shouldn't be forced on you.
You should always write code for someone else, not yourself. And I'd imagine all pieces of code could be improved before *or after* someone "checks" it regardless.
It would seem more arrogant to think other people's code needs fixing. I prefer trusting my team and their abilities.
I don't and never will like code reviews. But you shouldn't take that personally.
|
|
|
|
|
Code reviews WILL catch things that are wrong. Not just that could use improvement. That's not arrogance. It's teamwork.
|
|
|
|
|
How about double Value => Calculation() * (flag ? 1 : 2);
Now you don't need to deal with any variable names. =)
// E
|
|
|
|
|
in my real case there were 4 if statement that return either, 0, 0, w, 2 * w.
except w was not good. was asked to change it 3 times through afternoon long message ping pong. first to something else. then from aNumber to number. then from number to width.
|
|
|
|
|
Yeah sorry, my comment was pretty OT. I really don't like codereviews either but they do serve a purpose, when they're done properly. Fussing over the name of a variable is not doing it properly.
// E
|
|
|
|
|
Code should be easy to skim for the easy bits, so using descriptive variables is helpful, as is insertion of concise comments, but descriptive needn't be long.
Also, as long as you keep in mind the scope of each variable and are doing any trash collection that is needed by your language choice, then short names are fine, especially as iterators. Just don't be lazy and leave a variable living longer than it is needed.
|
|
|
|
|
see.. you obviously didn't read what I said.
I said it is much harder for me to read those long names.
I am cool though, however strange, I believe you when you said you find long names easier... I just beg, don't make me suffer for your personal convenience...
|
|
|
|
|
I did say that descriptive names need not be long, and that iterators need not even be descriptive. Clarity is the goal, so using a name like double_me for a flag might be all that's needed, leaving your input variable as x.
Did I say that long names are easier? I don't remember saying that.
|
|
|
|
|
One thing not mentioned in the other replies is the readability from the very first word.
In your example of
a = b + c
If a was named better then I wouldn't need to read the rest of the code to understand what I'm dealing with.
So in the long run I can gain general understanding at a glance. You should only need to dig deeper if you need to, and with each well described method and variable I can gain a better understanding.
Personally a = b + c is a bit lazy and I wouldn't want to have to maintain your code.
This talk on Clean code really hits the nail on the head for me when it comes to clean code - JeremyBytes Live! - Clean Code: Homicidal Maniacs Read Code, Too! - YouTube[^]
|
|
|
|
|
Super Lloyd wrote: And have to wait a few more hours because I was told 'not to use short variable name'.
Unsure I renamed 'x' to 'aNumber', but that irks me...
A huge mistake many developers make is thinking of the code as "my code". It is not. It is your employer's code which you are paid to write. As with most other jobs, you are paid to do what your employer wants, not what you want.
If the coding standard is to not use 1 character variable names, then it's the programmer's job to do what they are paid to do.
That said, the feedback provided was useless. Making an assumption, the feedback should have been "use variable names descriptive of the situation".
I've suffered the good, the bad, and the ugly with code reviews. The truly bad was sitting in a room for 8 hours with 10 developers, literally reading and critiquing EVERY line of code. The lead developer had no understanding of what the goal was and he was not one to accept anything remotely resembling criticism.
The best? Reviewers were provided with the code and instructions to identify violations of the coding standard, places where the processing was not clear, and suggest corrections. Review of 1,000 lines of C took about 30 minutes with 3 reviewers, as the few problems identified were diagnosed before the meeting so in meeting it was a matter of reach agreement.
|
|
|
|
|
why?
Because I am a software mechanic (engineer), and my first reaction is: "Who the F... wrote this?"
You will learn over time that a good code review by your best colleagues will preserve your reputation, and people like me won't have that kind of reaction when we look at your code.
"That's enough for me, please pass the album cover..."
 ![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
~d~
|
|
|
|
|
I would have thought the use of these names could be defended as "The scope of the name x was exactly two lines. It was used to make the code lines shorter and more readable."
|
|
|
|
|
I actually agree with you. The property name of "Value" makes sense as it's likely part of a larger class that has an outputted value. it's what I would look for browsing the class definition.
The 'x' variable is used in such a short space, that's it's fine by me, since Calculation should have the definition for it's return value. a longer name would take longer to read, and add more noise to something so simple.
A long time ago, I also subscribed to long variable names. like 'for' loops I used to us 'xloop', 'yloop', 'zloop'. but that was stupid, turned out it was way more 'noise' than worth while and started keeping the code cleaner like i, j, k..
for(int xloop =0;xloop<max; xloop++){total += data[xloop]}
or
for(int i=0;i<max; i++){total += data[i]}
I feel the second is way more easy to read. now if the variable was used over 10 or so lines, I would likely give it a much more meaningful name. but I look for clarity over hard rules.
Especially being a little dyslexic, the easier to read the better.
I once worked with a developer that would have written it like:
for(int intCounterForAccumulationLoop=0;i<maximumCountOfTheArrayBeingProcessed; intCounterForAccumulationLoop++){totalAmmountOfAccumulationFromTheDataArray += data[intCounterForAccumulationLoop]}
All three produce the same output, but the last one was by far the hardest to read and understand what was going on.
|
|
|
|
|
Put yourself in the imaginary position that you're someone who didn't write the code and has to understand what the author intended in order to be able to extend the functionality. It has to be understandable at the very first glance as if you were reading a book, because otherwise it's gonna take you hours because you get stuck every 1 1/2 lines and have to stop reading and try to guess: What does the author mean by "x"? The x axis? A cross? What does he mean by "cmp"? Component? Computer? Compare?
From that point of view, it should be obvious that it's kind of rude to treat other programmers like that. No?
|
|
|
|
|
Exactly, for me the change make it harder to understand.
Obviously people dont put themselves in my shoes.
|
|
|
|
|
|
Interesting critique of ITER. However, it misses one important point. Fusion power plants, assuming we ever manage to control the reaction, will have to be designed differently simply because they'll have a different output requirement from ITER. As the author points out multiple times, ITER is a research project and not designed to generate power. Fusion power will have to build on what's learned by ITER and other research facilities but they'll have a different goal - to produce power.
Where I think the author is right is in something he implied - fusion research so far has been nothing more than learning how to manage and control high temperature/high pressure plasmas.
|
|
|
|
|
The proud declaration “ITER will produce 500 megawatts of output power with an input power of 50 megawatts” as the author explains is a falsehood This suggests to me the project is corrupt and therefore doomed
A successful fusion power plant will of course have to be designed differently from ITER as according to the author ITER is doomed to failure due to its many "irremediable drawbacks"
Perhaps inertial confinement will succeed - Cheerio
"I once put instant coffee into the microwave and went back in time." - Steven Wright
"Shut up and calculate" - apparently N. David Mermin possibly Richard Feynman
|
|
|
|
|
So because the first one that actually has a chance of working will be a messy, expsensive, oversized string and duct tape affair that probably won't live up to the hyperbole, we should not bother?
Imagine if the Wright brothers felt the same.
cheers
Chris Maunder
|
|
|
|
|
Well, the guy waiting for his bicycle to be repaired certainly felt that way. 
|
|
|
|
|
Perhaps instead of "irremediable drawbacks" I should have said "apparent irremediable drawbacks which perhaps will be overcome in one-hundred or two-hundred or three-hundred years"
I am all for research of course I would be kinder to ITER if instead of their bold false deliberately misleading claim of unlimited energy they instead proclaimed "Maybe in a few hundred years this will work" Hopefully by then we will be running on wind solar tidal and who know what else Perhaps ITER will be useful then so yes we should press on with it but some honesty of ITERs' part would be appreciated - Cheerio
"I once put instant coffee into the microwave and went back in time." - Steven Wright
"Shut up and calculate" - apparently N. David Mermin possibly Richard Feynman
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
