[wink]
(The green squiggly is a little small; you should always check your full build for warnings every now and then instead of relying on the squiggly)
Prefixing names using some notation
About the empty statement issue:
[wink]
(The green squiggly is a little small; you should always check your full build for warnings every now and then instead of relying on the squiggly)
[wink]
(The green squiggly is a little small; you should always check your full build for warnings every now and then instead of relying on the squiggly)
Quote:Original post by Ariste
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.
Block is an artificial construct of some languages. Hell, the concept of a scope belonging to the conditional is more universal than the concept of a scope belonging to the block. Regardless, scope is perhaps the wrong term here. I meant more the actual instructions associated with the conditional.
Personally, I think that lines up a lot better with standard imperative thinking, which if you're using conditionals in the first place, follows nicely.
Quote: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.
I disagree.
if( something ){ doStuff();}is a lot less visually offensive to most programmers (for most environments) than
if( something ){ doStuff();}That added distastefulness makes it harder for programmers to resist the urge to condense things to
if( something ) doStuff();especially for coders who find the newline bracket distasteful in the first place due to excessive whitespace concerns.
It's not a problem with coders. Every coder has some fixed tolerance for ugly vs good. The newline bracket increases the ugly [edit: for single line conditionals], meaning more programmers tend to eschew the good to decrease the ugly. In my experience, YMMV, and all that.
[Edited by - Telastyn on April 29, 2010 2:55:34 PM]
Quote:Original post by Telastynif( something ){ doStuff();}
is a lot less visually offensive to most programmers (for most environments) thanif( something ){ doStuff();}
That added distastefulness makes it harder for programmers to resist the urge to condense things toif( something ) doStuff();
especially for coders who find the newline bracket distasteful in the first place due to excessive whitespace concerns.
Personally, I prefer the 2nd layout; I LIKE whitespace in my code.
Also, as noted, its safer for future expansion and adjustment of code.
void RenderingAgent::run(){ // Should probably signal this as an error if(singleThread) { done(); } SetupD3D11(window); Concurrency::send(completionNotice, 1); shouldQuit = false; numDrawCalls = 0; while(!shouldQuit) { RendererCommand command = Concurrency::receive(commandList); ProcessCommand(command); } RendererCommand command; while(try_receive(commandList, command)) { if(command.cmd) { command.cmd->Release(); } } ShutDownD3D(); done();}White space allows 'paragraphs' in the code; groups of logical functionality together in a larger context.
Still, if you really want to compress it down you can always do;
RendererCommand::RendererCommand(DrawingCommandType cmdID, ID3D11CommandList * cmd, DWORD time) : cmdID(cmdID), cmd(cmd), time(time){ if(cmd) { cmd->AddRef(); }}Best of both worlds...
Quote:Original post by Telastyn
Block is an artificial construct of some languages.
Not really. By its nature, an if-then conditional must contain some set of 'stuff' to be done/considered in case the conditional evaluates true. This set of 'stuff' is what I call a block. I'm not talking about programming languages here, but rather the fundamental notion of a conditional.
Anyway, this is very semantic. As I said before, it's mostly just a matter of preference.
Quote:if( something ){
doStuff();
}
is a lot less visually offensive to most programmers (for most environments) than
if( something )
{
doStuff();
}
What is and is not visually offensive is entirely subjective. The first example is far 'uglier' to me than the second. But I do see your point - you're probably more likely to get conditionals without brackets using the second method than the first.
Quote:Original post by YogurtEmperorQuote:Original post by AristeOr:
final = ballVel.Dot(dir);
final = ballVel.Cross(dir);
final = ballVel * dir;
And this way I don't have to backwards-deduce the nature of the operation by means of its return type. The only place where ambiguity might arise is in the last line (where ballVel could be either a float or a vector), but this is easily fixed by properly naming the variable:
final = ballSpeed * dir.
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.
If the guy writing your physics code doesn't know the difference between speed and velocity, you are screwed no matter what notation. =)
Quote:Original post by jykYou'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).
Some things I did not touch because I felt others had. Other things I did not touch because I am already spending too much time writing lengthy posts and longer posts are less likely to be read anyway.
Besides that, my friend died and my girlfriend left me on the same day and frankly I just don’t have the energy to hit every point.
Quote:Original post by jykQuote:Original post by ZahlmanI wondered this as well. In fact, I asked a similar question earlier in the thread:
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?Quote:Original post by jykI don't think YogurtEmperor ever responded to this point though.
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 responded with this:
Quote:Original post by YogurtEmperor
Even with naming conventions, people will be unreliable and make mistakes, but naming conventions are concrete in that the “what to do” can be clearly and explicitly defined. That is, “use meaningful and non-misleading names on variables” is a lot harder to follow than, “put a ‘p’ in front of pointers”. Aside from “misleading” being a relative term, some people simply don’t know about or think about the differences between “speed” and “velocity”.
If a person is likely to make mistakes on simply following a naming convention, he or she is probably more likely to also make mistakes related to improper naming, ambiguous overloading, etc.
Combine these mistakes with no naming conventions for a brew that will knock you off your feet in seconds.
Since naming conventions are non-subjective they should be easier to follow than picking “suitable” names, which in some cases relies on decent knowledge on one subject or another.
And as long as the naming convention is clearly defined, there can be no confusion as to what a prefix means by others reading the code later. People can argue colors—“Why did you name this ‘BlueGreen’? I would have named it ‘Teal’,”—but no one can argue the meaning of ui32*.
Perhaps that is why I prefer naming conventions. They are systematic, clearly definable, etc. These are the same reasons I like math and (love) science; I have since birth always enjoyed putting structure and logic to things.
L. Spiro
Quote:Original post by YogurtEmperor
no one can argue the meaning of ui32*.
First thing that came to mind was some sort of UI element.
Plus, your color argument exactly proves jyk's point: don't name it BlueGreen or Teal, name it based on its functionality - enemyColor.
Quote:Original post by nullsquaredQuote:Original post by YogurtEmperor
no one can argue the meaning of ui32*.
First thing that came to mind was some sort of UI element.
Plus, your color argument exactly proves jyk's point: don't name it BlueGreen or Teal, name it based on its functionality - enemyColor.
That's not the point, the point is that there are multiple ways to describe a thing, one not necessarily better then the other. Most people call pink things purple...there's often a gradient between 2 defined states, so it's mixed in the middle. There is nothing wrong with a convention, since a convention means consistency (or should) and as long as some funky convention is consistent, perfect! If someone chooses Hungarian, good, as long as he sticks to it. I would forbid it in my style guide though.
First thing that came to my mind is an unsigned integer, 32 fits well with that. A UI element, on the other hand, is rather unrelated to the number 32. Also, naming your variable simply "ui" when it's related to "some UI element" is neither really describe-full.
Quote:Original post by nullsquaredQuote:Original post by YogurtEmperor
no one can argue the meaning of ui32*.
First thing that came to mind was some sort of UI element.
That is exactly why I said “as long as the naming convention is clearly defined”, and it usually is.
Typically a company will have a document in place that clearly states the meanings of each prefix and when to use them.
Once each person has read the document, the meaning of ui32 will have been made clear to each person (whether that is a user interface or not).
If there is confusion, the document can be used to prove one person or another correct. This cannot be done with “descriptive” names.
L. Spiro
Quote:Original post by YogurtEmperorQuote:Original post by jykYou'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).
Some things I did not touch because I felt others had. Other things I did not touch because I am already spending too much time writing lengthy posts and longer posts are less likely to be read anyway.
Besides that, my friend died and my girlfriend left me on the same day and frankly I just don't have the energy to hit every point.
Quote:I responded with this:Fair enough, and sorry if I got a little overly invested in the discussion - whether one prefers this convention or that convention is certainly not that important in the grand scheme of things :)Quote:Original post by YogurtEmperor
Even with naming conventions, people will be unreliable and make mistakes, but naming conventions are concrete in that the "what to do" can be clearly and explicitly defined. That is, "use meaningful and non-misleading names on variables" is a lot harder to follow than, "put a 'p' in front of pointers". Aside from "misleading" being a relative term, some people simply don't know about or think about the differences between "speed" and "velocity".
If a person is likely to make mistakes on simply following a naming convention, he or she is probably more likely to also make mistakes related to improper naming, ambiguous overloading, etc.
Combine these mistakes with no naming conventions for a brew that will knock you off your feet in seconds.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
