Prefixing names using some notation

Started by
96 comments, last by phresnel 13 years, 11 months ago
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.


Ah yes, I ment to respond to this before; the difference here is the type of information being encoded. Instead of 'data type' you are encoding 'usage' information aka 'Apps Hungarian'.

The thiing is, I'm willing to bet that all of us here use a variation of 'apps hungarian' in our code; because it encodes not 'type' but 'intent'. The main difference is that instead of using short forms such a 'colCount' people use longer names, for example 'columnCount' mostly because we are't limited by 80 column screens any more and can see a bit more information at once.

So, 's' and 'us' strings, pertiularly in the web domain, make sense because you aren't encoding type.

I mean, if you were then you'd end up with 'ussUserName' for an unsafe string.. and that just sounds like a bad starship name [grin]
Advertisement
Quote:Original post by phantom
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.


Ah yes, I ment to respond to this before; the difference here is the type of information being encoded. Instead of 'data type' you are encoding 'usage' information aka 'Apps Hungarian'.

The thiing is, I'm willing to bet that all of us here use a variation of 'apps hungarian' in our code; because it encodes not 'type' but 'intent'. The main difference is that instead of using short forms such a 'colCount' people use longer names, for example 'columnCount' mostly because we are't limited by 80 column screens any more and can see a bit more information at once.

So, 's' and 'us' strings, pertiularly in the web domain, make sense because you aren't encoding type.

I mean, if you were then you'd end up with 'ussUserName' for an unsafe string.. and that just sounds like a bad starship name [grin]


I think it's better in languages with strong data typing to just enforce these kinds of things with the type system. It's never going to be wrong, and it won't forget.

If performance prevents the kind of wrapping I previously suggested, even c++ typedefs are fine (in this example, YourGame::UnsafeString and YourGame::SafeString to std::string). I don't see why anyone would prefer naming convention to this in a strongly typed language.
Quote:Original post by return0
Quote:Original post by phantom
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.


Ah yes, I ment to respond to this before; the difference here is the type of information being encoded. Instead of 'data type' you are encoding 'usage' information aka 'Apps Hungarian'.

The thiing is, I'm willing to bet that all of us here use a variation of 'apps hungarian' in our code; because it encodes not 'type' but 'intent'. The main difference is that instead of using short forms such a 'colCount' people use longer names, for example 'columnCount' mostly because we are't limited by 80 column screens any more and can see a bit more information at once.

So, 's' and 'us' strings, pertiularly in the web domain, make sense because you aren't encoding type.

I mean, if you were then you'd end up with 'ussUserName' for an unsafe string.. and that just sounds like a bad starship name [grin]


I think it's better in languages with strong data typing to just enforce these kinds of things with the type system. It's never going to be wrong, and it won't forget.

If performance prevents the kind of wrapping I previously suggested, even c++ typedefs are fine (in this example, YourGame::UnsafeString and YourGame::SafeString to std::string). I don't see why anyone would prefer naming convention to this in a strongly typed language.


I absolutely agree that ppl should use the typesystem more, in combination with other things like const correct code, this is a mighty tool to enforce compile time checks.

Unfortunately it's a bit non-trivial to introduce strong-typedefs upon the scalar types in C++ (as you can't derive from them) or classes that are functionally equivalent to other classes, yet distinct typewise, and further, using typedef for anything else than shortcutting something (in a small scope, C++0x will help out with auto) should be forbidden in any coding convention, because it totally circumvents all the benefits of strong typing, as C/C++'s typedef is really just an aliasing device which makes newbies think the wrong thing (even tho I am on the C++-side of things, I must say that typedef is probably one of the most misused things on the world).

I totally fall in love with D's distinction between alias-types and really new types, and wish that feature would be available in C++ (tho it wouldn't solve the problem of defining the right operator-sets for each entity; for those, derivation would be the solution, together with explicit ctor's and explicit type conversions).

sidenote: boost::strong_typedef can often help out, or just a thin class with a single scalar member, if you are careful. Here's a nice article.


oh, and sorry if my writing style is a bit tanked, this is a pre-sleep post :P
The remaining problem with strong/static typing is that typically they will not enforce all important rules, or will enforce wrong ones.

Typing can be an incredibly powerful tool, but each language contains only a tiny subset, and part of this subset is often solving the wrong problem. Consider the following code:
void foo(not_null<int> pI, positive<double> d);
not_null is a type which, in constructor and assignment, tests whether parameter passed is null. Assignments between two not_nulls don't need to be checked, since invariants are preserved. The above is quite practical and efficient way to enforce invariants with zero overhead in almost all cases (in C and C++ at least).

While the above could be used as a powerful error detection mechanism, one that would fail reliably during run-time (excluding corrupt values), compiler does not understand it. Similarly, positive type could easily enforce constraint during run-time, but would still compile for positive(-1).

Ability to strongly type values can prevent a lot of errors - but current crop of compilers only provides a certain subset of these rules, and some of them are of dubious benefit (signed - unsigned conversion).

Type inference could help with previous examples, but is again just part of the equation. Some languages provide annotations, and those can be tested during build. Then there is AOP, which involves instrumentation and compile-time processing.

What it comes down to is actually two opposites: fail-fast vs. fail-safe.

In many languages, NullObject pattern became popular. It solves number 1 issue in managed languages (the annoying NPE) and helps simplify error checking. Similar idioms could be applied at language level as well.

Hungarian notation is just one attempt to address these deficiencies. Why isn't columnCount typed as Column (trivial and somewhat consistent fix, but explodes in complexity)? Could compiler be taught about what a column is? At this point, things get pretty interesting - compiler might deduce that Page is Margin + n*Column + n*Spacing.

Or given Url and EmailAddress, compiler would be able to deduce that EmailAddress + Url = Url (with login information). Or that Server + FilePath = URI. And that Server can be assigned to either IP4 and IP6 types. And that Username + Server = EmailAddress as well as LoginCredentials.

But it gets better. pInt + 0x443827465 might equal ThreadStack[1154] (due to the way memory is organized. Or, pInt[4] would equal localVariable7. And it would be perfectly correct and legit, but would make many language and best practices purists scream in horror. But all perfectly safe, enforced completely by compiler.

Today, this missing link is provided by unit tests. But those need to be hand-coded for each project. For some checks, especially in strongly typed languages, the type system gets in the way. NullObject cannot be reliably enforced in Java (lack of pass value by reference). In C++, there are so many corner cases that any such rich typing becomes incredibly complex and error-prone to implement.

But mostly, the software industry doesn't really care. Effectively all problems today are adequately solved by large numbers of warm bodies. So why improve the process in such drastic way, when the savings would not outweigh the training and educational effort.
It might be a bit disrespectful to only answer with this short phrase for the positive-thingy or enforcing any number system (lacking time as always :/), but C++-0x will have one of my personal killer features, coined user-defined literals, which would give you the tool to describe e.g. positive doubles like 42.314159U (I am unsure if the U suffix is allowed for user defined literals), which is absolutely yay, if you ask me. It would even allow for compile time evaluation of sql-statements.

(one of my personal other killer features is constexpr, and for apps-programming, range-for)
Quote:Original post by phresnel
...C++-0x will have one of my personal killer features, coined user-defined literals


It sounds like one might be able to implement compile-time string hashing, too. That would be ridiculously badass.
Quote:Original post by Nypyren
Quote:Original post by phresnel
...C++-0x will have one of my personal killer features, coined user-defined literals


It sounds like one might be able to implement compile-time string hashing, too. That would be ridiculously badass.

Speaking of... it would be something similar to that.
Quote:Original post by Nypyren
Quote:Original post by phresnel
...C++-0x will have one of my personal killer features, coined user-defined literals


It sounds like one might be able to implement compile-time string hashing, too. That would be ridiculously badass.


or of course use a recursive constexpr function for that :D

edit: If I think a bit more about the sql-literal thingy, than hand writing a compile time parser might be tedious. Someone should write a, uhm, meta compile time parser generator, kinda boost::meta-spirit.

This topic is closed to new replies.

Advertisement