Quote:Original post by phantom
Quote:Original post by DevFred
Quote:Original post by YogurtEmperor
nothing pisses me off more than not being to immediately recognize the types and scopes of the variables I am seeing.
Types of variables are only one problem, but it is frustrating seeing a value being used and not immediately knowing whether it is a local, a parameter, a member, or, God forbid, a global.
If you cannot tell immediately whether a variable is local to the function, you have a problem: the function is too big. If it does not fit on one screen, it is too big. It does too much. Split it up. I would even argue that functions with more than 10 lines are too big.
Same with classes. If your class has more than, say, 100 lines, it is too big. Remember the single-responsibility principle. Let your class do exactly one thing. If it does multiple things, split it up.
Amen to this.
If you are writing functions which are so big that you can't track the local variables in use then you should refactor it.
I make a point of writing functions where I can see the whole thing on the screen at once; locals a clear, parameters are clear and members are clear. (I avoid globals, infact the 'g' prefix is the only one I'll use because it happens so rarely and it's a mental hint to myself to refactor that).
Frankly, if you've hit functions which are so long you can't see them all on screen you are going to have bigger problems than 'finding the type of a variable' because in scope that big you don't know whats happened to the variable by the time you get to it.
Maybe I need to reiterate this on a per-page basis.
Quote:Original post by YogurtEmperorI just want to be clear.
…
There are millions of ways to write code when you are in control, but, as Grafalgar reiterated, reading code is usually hardest when looking at code someone else wrote, which was the context of my example(s).
Without a doubt, you should be able to read your own code, regardless of any bad practices you may have used (ambiguous operators or not) or not used.
My examples are what you really may encounter when browsing other peoples’ code, if you are a professional game developer. And yes I threw in that misleading name (speed vs. velocity) on purpose as a compound example of mistakes people make. It’s common. People do that all the time, and you can’t always go by names to clarify code.
If I had had my own code in mind when thinking about the evils of no conventions, I would have already left the field of programming decades ago.
Your rebuttal suggests that naming conventions are an excuse for poor overall variable names. In fact someone even posted an example of it:
Quote:Original post by djzdouble dInput;int iInput;byte bInput;//is much less descriptive than this...double OriginalInput;int Input_IntRange;byte Input_ByteRange;
Why do people assume that adding a prefix means you are unable to also add a descriptive name? These things cannot coexist?
One extra character makes the name too long? Even though you are always going to copy-paste the name every time you re-access it anyway which means you only have to type the whole name once?
Wouldn’t
this be even
more descriptive?
double dOriginalInput;int iInputRange; // Also shorter, but if you had a reason for the long name you could also use iInput_IntRange.byte bInput_ByteRange; // Could probably be shortened! If "Byte" in the name is trying to tell me it IS a byte (as apposed to just working WITH bytes), // wouldn't a "b" prefix convey the same meaning with fewer characters? Easier to read and type. // You just don't want to do it because if you do it once you have to do it everywhere.
Now when I look at
you code long after you have died I can easily tell the types of each, and I will know that bInput_ByteRange is a byte and so can count only a limited number of items. Input_ByteRange doesn’t tell me that it
is a byte. Maybe it works with bytes in one of the numerous possible ways it could, but is actually an int.
#1:
IDE’s are not meant to be a crutch. Not everyone is using the same IDE. You can’t argue how easy it is for
you to use
your IDE to accomplish a task that is still slower than reading a prefix (for example). That has
nothing to do with people who are going to use your code later.
#2:
What seems to be a descriptive name to you may easily be misleading (speed vs. velocity) or at least non-descriptive to someone else.
a: Naming conventions have clearly defined rules. Everyone knows m_ = member, p = pointer, etc. This is not subjective.
b: Naming conventions coexist with “descriptive” names quite well. Why would you assume that using a prefix (for example) is going to cause the rest of the name to be less descriptive? The only time when a prefix would cause a change in the overall name is when the prefix duplicates information that was in the name, such as Input_ByteRange, in which cases the prefix is always shorter anyway, allowing those precious shorter names everyone wants.
#3:
You are not coding for yourself. You are coding for the others who are going to maintain your code after you die. It doesn’t matter how aesthetically beautiful your code is
to you. As I said before, we already know you can read your own code. This is like some guy coding in Swahili (variable names, comments, etc.) and then saying, “My code reads like prose, is very clear, and uses descriptive names.” That’s super, but he coded for himself, and he graded his own work subjectively. No one else can read his work or carry on after him. Code is not meant to be pleasing to your own eye. After functionality, it is meant to convey as much information as possible about what it is doing, so that when someone else comes along to add something to it, he or she has all that information ready at his or her fingertips.
#4:
Nothing is redundant about naming conventions.
Aesthetic coders tend to omit prefixes (as an example) or use conventions that do not relay that much information. The first time they see prefix-based conventions they think, “Ew, that’s ugly.” They prefer code like this:
res = left + right;
rather than code like this:
iRes = iLeft + uiRight;
The names (without prefixes) are equally descriptive. And we have information in the latter case that might cause us to do some error checking and possibly improve stability.
The only reason people would choose not to use this type of convention is that it is simply not “beautiful”. Aesthetics matter more than information to aesthetic coders.
I still remember the time years ago my old boss asked me to add a _ prefix to function parameters. I did it to follow orders, but it felt “ugly”, and I cringed every time I did it.
People don’t like cringing when they code. It’s that simple.
That is the root cause of people avoiding prefixes.They saw them at a young age, held “code beauty” at a very high importance, and decided, “that looks ugly; I won’t do it.”
This is also exactly why there are so many styles out there. The number of styles of coding there are is a testament to how widely people’s taste for “beautiful” varies.
If you don’t believe it, answer this: Do you think your code is ugly?
Obviously not. We all like our own styles. No one writes code he or she thinks is horrendously ugly.
So then, why
not use prefixes (for example)? Because they clearly do no harm. So why not?
Because you think they are ugly. They make you cringe from an aesthetic point and you don’t want to cringe at your own code.
Consistency is still the most important thing. When I work on a project that has no clear convention, or at least no prefixes, I code that way too, just for the sake of having all of the code look the same. I cringe when I code, and I hate it. We are
all susceptible to the cringe factor, but at the end of the day, consistency and the relay of information is simply more important.
I am clearly a proponent of naming conventions, and prefix-based ones are fine-by-me, but people don’t change after they have made up their minds.
I hope at least the original poster takes everything into consideration.
I feel I have made strong points, but there is no way to make everyone agree on this subject and taking it beyond this is too much of a waste of time (no really, look at how much I have typed in these last few posts!)
L. Spiro
[edit by phantom:adjusted code block to fix forum layout][Edited by - phantom on April 29, 2010 3:48:49 AM]
