Prefixing names using some notation

Started by
96 comments, last by phresnel 14 years ago
Quote:Original post by Grafalgar
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.


Ah, well you see, I don't consider the braces to be part of the scope, in much the same way that I don't consider quotation marks to be part of a quotation. So to me, the convention simply asks you to remember that indentation denotes the contents of a scope - and that's the same whether you give the opening brace a new line or not.

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


"used in the same way"? I can't extract any sense out of this argument; you seem to be saying that in either case, you should do what the language requires you to do. Well, duh.
Advertisement
There is a valid argument against some types of prefixs. They should not be used to denote the storage type of a variable such as iData to show that Data is an integer. This is bad because it damages information hiding and makes modifing the storage type of Data more difficult. If Data was changed from an integer to a long then you would be forced to alter the prefix everywhere in the code.

Information hiding would also seem to suggest that prefixing say UI to indicate that the Data belongs to the User Interface is also a less the good practice. It is generally better to create an access routine such as GetUserInterfaceData()and keep Data itself private.

I do like putting p in front of pointers so that a pointer to Data becomes pData. It makes the treatment and naming of pointers more consistant and makes it obvious whether I intended to use the pointer to Data or the Data itself. It also seem to be a common practice. I could use DataPointer or PointerToData but in some contexts they are not as clear as they appear to be and do require a lot more typing which can matter a lot when variable names get complicated.

When you start encoding data into identifiers that are meant to aid human understanding, you've taken a wrong turn somewhere.
"Walk not the trodden path, for it has borne it's burden." -John, Flying Monk
Quote:Original post by Zahlman
Ah, well you see, I don't consider the braces to be part of the scope, in much the same way that I don't consider quotation marks to be part of a quotation. So to me, the convention simply asks you to remember that indentation denotes the contents of a scope - and that's the same whether you give the opening brace a new line or not.


I'm not arguing the indentation of all the functionality inside of the scope, I'm explaining you why I have a hard time reading code which has only the starting brace not on its own line.

Let me say it again, because I'm sure you missed it: In that style, the scope entry and exit are not exact opposites of each other. Scope entry is visually defined one way, and scope exit is visually defined in other. If I wanted to visually define my scope using indentation alone, I would place the ending brace at the end of the last line, completely prohibiting them from functioning as visual cues. Whatever the style, I would expect to either see both braces or none at all, but none of this half-way stuff.

Quote:
"used in the same way"? I can't extract any sense out of this argument; you seem to be saying that in either case, you should do what the language requires you to do. Well, duh.


*sighs* - what I meant is that in python you use indentation to define scope. It's both functional and visual. Since C/C++ uses braces to functionally define scope, I expect them both to be visually clear as well.

[Edited by - Grafalgar on April 30, 2010 3:51:16 PM]
Regarding {} placement...

Thank God for code beautifiers... When I get code in a format I dislike I just let the built in beautifier in my IDE clean it up.
So much cool story bro in this thread...


Without knowing the purpose of the code being written, it's impossible to properly evaluate any of the suggested conventions.

For example, most here (including me) seem to agree that "systems hungarian" (i.e. iIngeger, flFloat, etc) is a pretty bad idea.
However, it is possible to imagine some low-level piece of system code somewhere where the actual problem being solved is focused directly on data-types and memory layouts. In such a piece of code, the code (which is a solution to this problem) could well be more understandable, easier to read, and make errors look more obvious if a "systems hungarian" notion was used.

Such a case is pretty unlikely, but the point is, there isn't one correct naming convention which is perfectly optimal for both web-style-sheets and virtual-machine-compilers...
Quote:Original post by BrianLarsen
Regarding {} placement...

Thank God for code beautifiers... When I get code in a format I dislike I just let the built in beautifier in my IDE clean it up.


Oh that is the pest in version control and when receiving upstream you possibly want to patch. Personally I skip that and just adapt my style temporarily to the one used in the source file.
Quote:Original post by CowboyNealFor example, sometimes you want to know if a String is an unsafe string or safe string. They are both type String, compiler will not help you out and Intellisense won't either, but that information can be very useful to know.



Just write these adapters?

class SafeString {    public string Value { get; private set; }    public SafeString (string safeStringValue)    {        Value = stringValue;    }}class UnsafeString{   public string Value { get; private set; }    public SafeString (string unsafeStringValue)    {        Value = unsafeStringValue;    }}public void ProcessString(SafeString input){    //do something}public void Foo(UnsafeString input){    ProcessString(input); //error}
Quote:Original post by phresnel
Oh that is the pest in version control

Why does version control consider whitespace? Wouldn't it make more sense to be token-based, except for comments? I understand the version control would then need to know the language, but still... would seem like a great feature to me.
Quote:Original post by DevFred
Quote:Original post by phresnel
Oh that is the pest in version control

Why does version control consider whitespace? Wouldn't it make more sense to be token-based, except for comments? I understand the version control would then need to know the language, but still... would seem like a great feature to me.


Version control is useful for many, many more things than just source code control, such as documentation, management of external dependencies, and the list goes on and on.

Edit: and I don't mean to poo poo this idea too much, because I think it would be great to have selective tokenization of certain files in a version control system for independent "viewing," but I don't think it is feasible to create a one size fits all solution in this manner.

[Edited by - arbitus on May 3, 2010 9:28:05 AM]

This topic is closed to new replies.

Advertisement