I don't like code reviews

[Super Lloyd]

If you use Git you are likely, but not necessarily, to have review. (not using Git here thought) At any rate, certainly, every now and then there is very good feedback in review. However every single time it waste a lot of time.

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[harvyk0]

We have a rule, if an acronym is well known, then we use it (eg url rather than universal resource locator), otherwise we spell out the full words. A few years ago we where working on a system which had a limitation on some names, but we needed those names to be descriptive of the keys. We ended up with a jumble of 3 letter acronyms everywhere. Sure enough, the parts we touched frequently where easy enough to deal with, but gee looking at some of the sections which remained fairly static was a nightmare to determine what was going on and what held what data.

[Super Lloyd]

you missed the part where I was talking about a variable.. inside a method...

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Wizard of Sleeves]

Right, tell your maths lecturer to use long variable names, instead of x and y.

Nothing succeeds like a budgie without teeth.

[Mike Winiberg]

In an IT class I had to help someone who was a competent coder, but had a similar problem (he was dyslexic). The course specified that you should use descriptive variable names (fortunately not hungarian though). We reached a compromise: he could use short variable names wherever possible (eg inside small functional units of code - as per your example) but had to add a comment at the start of the code that explained what the variables represented. This had to be only in code that could fit on the screen so it could be read in one hit. Ignoring - for now - the fact that no developer I've ever met (including me!) is good at keeping comments in step with the code, nevertheless this seemed a workable compromise: He could write code he could follow and there was at least a reasonable chance that the comments would give a good hint as to what was going on.

[harvyk0]

I've also seen enough var x = 1; var y = 2; var z = 3; type code in methods to know that single letter / acronym variable names can be bad, especially that method has grown a little too big. Whilst variable names should never be war and piece, they should be somewhat descriptive enough so that as a developer you know what values you're likely to see in there, and how they should be used. That said, I'll happily use for (var i = 0; i < 10; i++) {} without thinking twice, so you know I'm not 100% dedicated to the no small variable names cause.

[Member 9167057]

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.

[Super Lloyd]

Haha... 25 years and 20,000km too far and too late

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Matthew Wilcoxson]

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.

[Eric R Johansson]

How about double Value => Calculation() * (flag ? 1 : 2); Now you don't need to deal with any variable names. =) // E

[Super Lloyd]

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.

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Eric R Johansson]

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

[Cpichols]

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.

[RooN3y]

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[^]

[BryanFazekas]

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.

[Super Lloyd]

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...

A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!

[Eric Lapouge]

for (int room = 0, roomCount = rooms.Count; room < roomCount; room++)
{
rooms[room] = new Room();
}

Il just refuse anything else than something like this, my point of view

[Cpichols]

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.

[Eric Lapouge]

for (int room = 0, roomCount = rooms.Count; room < roomCount; room++)
{
rooms[room] = new Room();
}

room can be replaced by pos (or anything more meaningful); anyway: anything not like this as a code will not go live for me... Besides this point, when I had to manage core reviews, I dit it with the whole team so anybody could have seen and emphasis on different things and not only what I wanted to pinpoint. One point missing, is that code reviews in 2021 aren't the same as those done in the 1990: now we have tools like R# Shart (no publicity intended) which are removing a lot of "discrepancies" (bugs), automating test tools, and so on. So now, code reviews are more about code's readability and maintenance. Because of these (hey folks, dont forget you're using Intellisense which types most of the code for you!), so definitively no excuse to have readable code.

[etkid84]

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..." :cool::java:

~d~