Back to General and Gameplay Programming

Prefixing names using some notation

L. Spiro · 2010-04-28T06:27:09

I just want to be clear.Revisions to my sample are not unwelcome, but I don’t want the point of the code to be lost.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.[EDIT]I also want to reiterate the purpose of naming conventions in the first place. Naming conventions are first and foremost for the benefit of other people who have to read your code.It is assumed that you yourself can read any style you use, and you can look at code and recall the idea you were expressing at that time, with or without name prefixes.Additionally, code that “reads like prose” is subjective. Everyone thinks his or her code is clear and beautiful. A clear name to one may not be a clear name to another (speed vs. velocity comes to mind again here). What is prose to you may be nails on a chalk board to another.And this applies to art, music, and everything else. We can’t grade our own code. We can’t rate ourselves.Forget the fact that you are writing the code. Think about others who are going to read it later. Other people may not have the same IDE as you. Other people might not be as fast as you at clicking this or that. Other people don’t hold an encyclopedia of variable names + types in their heads as well as you do, and may end up having to re-check the type information of a variable several times.[/EDIT]L. Spiro[Edited by - YogurtEmperor on April 28, 2010 6:27:23 AM]

General and Gameplay Programming Programming

Started by Giedrius April 27, 2010 05:30 PM

96 comments, last by phresnel 14 years ago

Zakwayda

2,389

April 29, 2010 11:56 AM

Quote:Original post by YogurtEmperor
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!)

You're right that there's probably not going to be any agreement on this, and at this point, any further argument would probably just be repetition (there have been some arguments made against type prefixes - including counter-arguments to your arguments - that I don't think you've addressed or responded to in any of your posts, but I imagine repeating them again here probably wouldn't do much good).

I am going to throw out one more thing though. I'm a little embarrassed to admit that I spent time doing this, but I quickly looked through the source code of a fairly large selection of open-source libraries to see what sort of naming conventions they use. Some of these libraries are very well known and widely used, have very large code bases, and presumably have been worked on by many different developers over the years. Interestingly, only one of the libraries I looked at (out of about 20) uses type prefixes (as far as I can tell, at least).

Maybe I just got lucky and happened to randomly pick libraries that reinforce my own point of view. Or maybe type prefixes are more commonly used in closed-source projects or other code bases that I don't have access to. Another possible explanation though is that not that many people are using these sorts of naming conventions. If using type prefixes was 'the best' way to do things, wouldn't more of these projects be using such a convention?

Again, although I prefer no type prefixes, I think individuals/teams should use whatever works best for them, and I wouldn't presume to say that my preferred conventions are better than someone else's. Really, the only reason I've continued to post is that you seem to be arguing for type prefixes as 'the' right way to do things, which I disagree with. (Apologies if I've misinterpreted your arguments.)

Telastyn

3,778

April 29, 2010 12:09 PM

Quote:Original post by Konfusius
Quote:Original post by phantom
(honestly, there is a special place in hell for the people who decided that having the opening { on the same line as the function name/for/if was a good idea and in some way 'clear').

I wonder what's so bad about this convention, and what's better about your style.

Indeed. The indentation provides a better visual cue than the brace.

I've always had the mental model that the brace is associated with the conditional (and should thus be on the same line). Do you really think of it as 'if; block;' rather than 'if-begin scope; stuff stuff stuff; end scope;'?

The main problem with newline bracket coders I've seen is their tendency to omit the braces for 1-line conditionals (because the newline brace makes a lot of whitespace for something simple). This practice is way more likely to create bugs than anything same-line bracket code causes, at least in the modern age with auto-formatters to unerringly provide the key indentation cues.

-- Tangent Developer Journal - Delegates - Part 2

Zahlman

1,682

April 29, 2010 12:18 PM

Quote:Original post by YogurtEmperor
Speed vs. velocity is exactly what I meant by misleading names.
Basically, the problem boils down to people not being reliable. You can’t trust them to write meaningful names, lots of comments, non-ambiguous code, etc.
These are real-world examples that people commonly do, like it or not.

Well, if you can't trust them to pick the right word for a variable name, why the hell would you trust them to pick the right prefix out of your naming convention?

Zahlman

1,682

April 29, 2010 12:19 PM

Quote:Original post by phantom
oh, and { and } always ALWAYS go on their own line, with the scope 1-tab inside to show scope.
(honestly, there is a special place in hell for the people who decided that having the opening { on the same line as the function name/for/if was a good idea and in some way 'clear').

God damn, phantom. You're a moderator. You should know better than to troll like that. 8)

Zakwayda

2,389

April 29, 2010 12:26 PM

Quote:Original post by Zahlman
Well, if you can't trust them to pick the right word for a variable name, why the hell would you trust them to pick the right prefix out of your naming convention?

I wondered this as well. In fact, I asked a similar question earlier in the thread:

Quote:Original post by jyk
If programmers are expected to be unreliable, how is using Hungarian (or a variant) going to help? An 'unreliable' programmer could easily change a variable's type without changing the name, or maybe even use the wrong prefix to begin with, which completely defeats the purpose of using the naming convention in the first place.

I don't think YogurtEmperor ever responded to this point though.

Zahlman

1,682

April 29, 2010 12:34 PM

Quote:Original post by Grafalgar
Speaking for myself, I simply can't read it. It seriously gives me a headache. I have to consistently scan up and search for a line with an lesser indentation.

Even small (~10 line scopes) give me a hard time :P It's simply much faster to glance up, locate the "{", and then move on.

How is it any different to search for a line that starts with non-space in the same column than it is to search for a line with '{' by itself in the same column? Either way you look vertically straight up for the first row without whitespace in that column, and then check if it contains what you're looking for.

Quote:Then I have to make sure that it's the correct scope by searching for the opening '{', since oftentimes programmers check in code with inconsistent indentation.

Sorry, but if programmers check in code with inconsistent indentation, then you can't just "glance up and locate the '{'" no matter what. Observe:

if (foo){    if (bar)    {        something;} // oops, I actually match the if (bar)

That works the same way whether braces are on the ends of lines or not. If the other people on your team lack discipline in this regard, then your only recourse is to count braces. And that's assuming they have the discipline to only check in code that compiles. ;)

Or you could, you know, use an IDE that matches up the braces for you. In vim, for example, you just highlight a '{' and use the % command, so it really doesn't matter what your convention is.

In general, your teammates being inconsistent is not a reason to choose one convention over another. It is merely a reason to choose a convention. Unless, of course, you've identified a specific class of error your team tends to make, and can explain why that choice of convention specifically reduces the likelihood of that class of error.

For example, here is one example of a common class of error with some programmers:

if (some condition);{    // Oops, this is an anonymous scope whose contents always run.    // Note the semicolon.}

You may laugh and say that nobody could make an error like that, but I've seen numerous "help me fix my code" threads on GDNet where the problem boiled down to exactly this sort of thing.

So here is how doing braces the other way reduces the likelihood of that error:

if (some condition) ;{// WTF? ";{"? That looks wrong.

Now, I don't particularly care about this, but it's an example of an argument I could actually agree with.

Quote:Original post by szecs
It is so easy for you guys, who can see well. But the problem with '{' at the at of same line: what happens if you have to break that line, because you have to use a font in the IDE that you can see? And hell, I wouldn't scroll horizontally, even if someone was screwing my guts with a hook.

Then you scan vertically upwards for the first line with non-whitespace in the column with the '}' - same as you'd always do when you put '{'s at ends of lines - and find the 'if', i.e. the beginning of the statement that opens the scope. I would say that's more convenient, if anything.

Decrius

100

April 29, 2010 12:37 PM

Quote:Original post by Telastyn
Quote:Original post by Konfusius
Quote:Original post by phantom
(honestly, there is a special place in hell for the people who decided that having the opening { on the same line as the function name/for/if was a good idea and in some way 'clear').

I wonder what's so bad about this convention, and what's better about your style.

Indeed. The indentation provides a better visual cue than the brace.

I've always had the mental model that the brace is associated with the conditional (and should thus be on the same line). Do you really think of it as 'if; block;' rather than 'if-begin scope; stuff stuff stuff; end scope;'?

The main problem with newline bracket coders I've seen is their tendency to omit the braces for 1-line conditionals (because the newline brace makes a lot of whitespace for something simple). This practice is way more likely to create bugs than anything same-line bracket code causes, at least in the modern age with auto-formatters to unerringly provide the key indentation cues.

Indeed, I think of it as 'if; begin scope; stuff stuff stuff; end scope;'. By symmetry arguments you could say: why does the begin scope bracket DO belong to the if statement, and the end scope bracket NOT?

Also for one line blocks I ALWAYS use brackets, I also never make any indention exceptions...I'm a perfectionist here but I think it cost me less time in the end. Having begin and end brackets beneath each other is just so neat.

I don't dispise bracket-on-same-line-as-if-statement programmers, as long as there is consistency of course, but I wouldn't do it myself. Luckily Code::Blocks can automatically Astyle the code :D

[size="2"]SignatureShuffle: [size="2"]Random signature images on fora

Ariste

296

April 29, 2010 12:41 PM

Quote:Original post by Telastyn
I've always had the mental model that the brace is associated with the conditional (and should thus be on the same line). Do you really think of it as 'if; block;' rather than 'if-begin scope; stuff stuff stuff; end scope;'?

I've read the argument that the open bracket is a logical component of the if/else/for statement. I forget exactly what the argument was, but to answer your question: yeah, pretty much.

Scope is a construct of the language. 'if-begin scope' is very technical way of interpreting an if statement: it's technically correct, but actually the notion of scope is entirely orthogonal to the notion of an if-then conditional. There is no scope in the "real" world; brackets are a law imposed on us so that computers can understand what we're saying.

So yes, I think of it like 'if; block;' because to me it better reflects the basic nature of an if-then conditional.

Quote:The main problem with newline bracket coders I've seen is their tendency to omit the braces for 1-line conditionals (because the newline brace makes a lot of whitespace for something simple). This practice is way more likely to create bugs than anything same-line bracket code causes, at least in the modern age with auto-formatters to unerringly provide the key indentation cues.

Agreed, but this is more of a problem with the coders than with the convention.

Virtual Reality

Decrius

100

April 29, 2010 12:42 PM

Quote:Original post by Zahlman
Sorry, but if programmers check in code with inconsistent indentation, then you can't just "glance up and locate the '{'" no matter what. Observe:
if (foo){    if (bar)    {        something;} // oops, I actually match the if (bar)

"Hey, there's suspiciously much space between the 'something;' indention and the last bracket ;) => bracket forgotten!". To me it looks very red-flag-waving, this piece of code.

if (foo) {    if (bar) {        something;} // oops, I actually match the if (bar)

Actually, there's barely any difference if I'm honest, the only thing that bothers me now is that I'm not used to it.

As long as there is consistency, WHO CARES? :)
(disclaimer: assuming there is nothing radical going on).

[size="2"]SignatureShuffle: [size="2"]Random signature images on fora

RabblePants

548

April 29, 2010 01:13 PM

Zahlman, if we modify this style by saying neither braces are to be found on their own lines, I may find it much easier to get used to the style. Ex:

void foo(){     int i = 0;     i++;}

However, that not being the case, I find it very difficult to adopt (and read) a convention that asks me to remember that indentation starts scope, but an ending brace with one less indentation ends it. That, to me, is not a very logical 'pairing' of functionality, ie they are not complementary.

Compare to Python where the rule says indentation increase enters a new scope, indentation decrease exits scope. C++'s syntax, of course, enters a new scope with {, and exits it with }, and so I expect to see them used in the same way, however you define that to be.

Quote:
if (some condition) ;{
// WTF? ";{"? That looks wrong.

Hmm, that's the first real compelling argument for that style I've seen. Now, as I've said though, modify the style to have ending braces at the end of the last line and I'm all for it :)

[Edited by - Grafalgar on April 29, 2010 1:13:53 PM]

Prefixing names using some notation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Prefixing names using some notation

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines