|
design by committee... the plight of any big corp! ^_^
|
|
|
|
|
The code bases of the existing Adobe products I worked on, PhotoShop, Illustrator, were the opposite of design by committee: they grew by accretion. New, "hot," features always took precedence over any systematic re-org.
By the way, I have complete respect for the world-class programmers I had the chance to work with, and, I felt continually humble in their presence ... for good reasons: I was a one-trick pony 
When they did the PC version of PhotoShop, they found the Mac code (using the MacApp framework) impossible to port "native," so they re-implemented MacApp on Windows, which took a tremendous effort. [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Variable names should be long enough to explain what they do but short enough to be succinct. Very long names show you haven't thoroughly worked out what they are for or you are being too restrictive.
For example, the other day I was writing some code that I hadn't thoroughly thought through and I created a variable called something like locationOfCommonSharedValuesBeforeTheConfigurationWasJoinedToAnotherEnvironmentsConfiguration. After much soul searching, it is now called originalSharedValues.
|
|
|
|
|
Super Lloyd wrote: For example a simple expression like a = b + c
can confuse me if you write instead myobjectBlu = aCycleValueOrdinal + meteorStrikeOffsetTime.
Good example.
Without greater context, I can't tell whether "b + c" is the correct thing to do to get "a".
Given your second example however, if I know that in order to get myobjectBlu, the equation needs meteorStrikeOffsetTime to be multiplied by a constant before being added to aCycleValueOrdinal, then I can spot this.
[Edit]
Just being devil's advocate. I have to imagine that someone reviewing this would see the greater context and not just look at the one line.
|
|
|
|
|
Super Lloyd wrote: double Value
{
get
{
var x = Calculation();
return flag ? x : 2 * x;
}
}
Here's my comment - do NOT use var! Using var instead of double forced me to look in a second place in your code to figure out what I was reading. var is an abomination.
|
|
|
|
|
obermd wrote: var is an abomination.
when used improperly.
Our shop uses var all the time.
var myClass = new MyMostExcellentClassInTheWholeWideWorld(); this is acceptable IMHO and the opinions of hundreds of thousands of developers world wide, if not millions, billions, and trillions.
var something1 = something2.GetSomething3(); this is not acceptable.
This is a hotly debated topic, I know. To each there own.
|
|
|
|
|
and now, C# 9 brings you "even more naked" instantiation:
List<int> xs = new();
List<int>? ys = new();
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
BillWoodruff wrote: List<int> xs = new();
List<int>? ys = new();
stuff like this is just retarded.
it is really for the people who hate "var". These people want to see the instantiation on the left, rather than the right.
It makes me laugh and cry all the way home.
modified 7-Sep-21 10:28am.
|
|
|
|
|
This works as well because it's obvious from the single line of code the type of the variable.
|
|
|
|
|
This example works because the class name is in the same line of code.
|
|
|
|
|
I agree, the length of a variable name should be proportional to its scope and visibility.
The reader should be able to see a one-letter variable and just know that it has only local scope. Any developer who gets confused by such a thing does not belong on my team.
The fewer the characters, the easier to read. 
|
|
|
|
|
Thinking about my own code I realize I do this as well. Descriptive names for globals or widely used variables and functions and short names for local use only.
|
|
|
|
|
In 23 years, I've never had my code reviewed. I feel lucky!
"Go forth into the source" - Neal Morse
"Hope is contagious"
|
|
|
|
|
I use "i" in for loops. That's it.
Edit:
Also using "x and y" currently: for position coordinates.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I use descriptive names, which tend to be long.
Short names in my code depend upon context. Here's an example:
for (int JMi = 0; JMi < JettingModules.Length; JMi++)
{
JettingModules[JMi].DoStuff(...);
}I will occasionally use short names synonymously to long names in order to make a complex expression simpler to understand or read:
bool ready = StitchCalibration.Context.Ready(...);
bool online = Framework.Online && DFE.Service.Connected;
int retry = 0;
while (ready && online && (retry < 3))
{
}My names are chosen to tie related concepts together and for clarity of expression.
Software Zen: delete this;
|
|
|
|
|
"depends on context"
Amen !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Greetings My code has never been reviewed but am curious if it were I might learn something or teach the reviewer a thing or two Wouldn't mind reviewing others' for the same reason- Cheerio
PS As for naming It seems obvious names should be as long as necessary to indicate intent when they set context Short is fine once context is set Also the name can indicate the type and value range of the identifier e.g. "calculateWidth_ofImpendingMeteorStroke" will never return a negative value Further have some sympathy for the poor chap who will maintain the code or for yourself many months or years hence Further I like to utilize different naming conventions to indicate the scope of the identifier I always utilize snake for local and now tend to camel for class and prefix with a 'g' for the rare global
"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
|
|
|
|
|
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.
|
|
|
|
|
Right, tell your maths lecturer to use long variable names, instead of x and y.
Nothing succeeds like a budgie without teeth.
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
