June 01, 2005
"Hasan Aljudy" <hasan.aljudy@gmail.com> wrote in message news:d7l6oo$2gtm$1@digitaldaemon.com...
> Brad Beveridge wrote:
> > David Medlock wrote:
> >
> >> Regan Heath wrote:
> >>
> >>> http://joelonsoftware.com/articles/Wrong.html
> >>> An article by "Joel Spolsky".
> >>> I loved it.
> >>>
> >>> Regan
> >>
> >>
> >>
> >> His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
> >>
> >> His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
> >>
> >> -DavidM
> >
> > Really, what it boils down to is "give your variables sensible names". D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
> >
> > typedef int rowType;
> > typedef int colType;
> >
> > rowType r;
> > colType t;
> >
> > r = t; // D compiler will catch this.
> >
> > So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be
implicit.
> >
> > Brad
>
> Indeed, I think you only need something like hungarian notation is when
> you don't have strong types.
> safe and unsafe strings should have different types, and the function
> that is used to retrive user input, should return it as an unsafe string.
> This way, you wouldn't need to prefix variable names.


Part of the problem here is that some people (in MS, as I understand it) would write function bodies of prodigeous and alarming proportion (CS was one). Given that, it was nigh impossible to eyball the code and locate data types. This behaviour should have disappeared with GWBasic, but not for some folks.

Regardless of the type-system or design approach used (including OOP), concise bodies of code can help tremendously. There are always exceptions though, and YMMV.

Without intending to offend anyone's sensibilities, I feel Spolsky's article is targeting those who have little or no concept of structured coding.

Further; while he identifies behaviour such as "cleaning house" and refactoring as being forerunners to full-blown AppHungarian syndrome, I feel that's a different attribute altogether. I mean, Ben is discussing doing the same thing with Phobos right now ~ I don't think he's about to suggest introducing Hungarian to D ~ are you, Ben?

But the history of contorted-evolution was interesting :-)


June 01, 2005
On Wed, 01 Jun 2005 14:45:19 -0600, Hasan Aljudy wrote:

> Brad Beveridge wrote:
>> David Medlock wrote:
>> 
>>> Regan Heath wrote:
>>>
>>>> http://joelonsoftware.com/articles/Wrong.html
>>>> An article by "Joel Spolsky".
>>>> I loved it.
>>>>
>>>> Regan
>>>
>>>
>>>
>>> His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
>>>
>>> His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
>>>
>>> -DavidM
>> 
>> Really, what it boils down to is "give your variables sensible names". D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
>> 
>> typedef int rowType;
>> typedef int colType;
>> 
>> rowType r;
>> colType t;
>> 
>> r = t; // D compiler will catch this.
>> 
>> So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be implicit.
>> 
>> Brad
> 
> Indeed, I think you only need something like hungarian notation is when
> you don't have strong types.
> safe and unsafe strings should have different types, and the function
> that is used to retrive user input, should return it as an unsafe string.
> This way, you wouldn't need to prefix variable names.

I agree that a good type system caters for previous uses of Hungarian notation. However, I use prefixes on variable names to indicate scope. This serves the same premise that the author was promoting, namely that a person doesn't have to read a lot of code far from the current line to gain useful information about the variable.

Examples:
 pText  ~~ 'p' indicates that this is a parameter passed to the function.
 lScale ~~ 'l' indicates that this is scoped to the function or block.
 vHigh  ~~ 'v' indicates it is scoped to the module
 gRow   ~~ 'g' indicates it is globally scoped ie 'public'
 mStyle ~~ 'm' indicates it is scoped to the class 'private'

-- 
Derek Parnell
Melbourne, Australia
2/06/2005 7:24:50 AM
June 01, 2005
In article <sfj3zr1o3hx8.1q4wcqi7mqbsl.dlg@40tude.net>, Derek Parnell says...
>
>I agree that a good type system caters for previous uses of Hungarian notation. However, I use prefixes on variable names to indicate scope. This serves the same premise that the author was promoting, namely that a person doesn't have to read a lot of code far from the current line to gain useful information about the variable.
>
>Examples:
> pText  ~~ 'p' indicates that this is a parameter passed to the function.
> lScale ~~ 'l' indicates that this is scoped to the function or block.
> vHigh  ~~ 'v' indicates it is scoped to the module
> gRow   ~~ 'g' indicates it is globally scoped ie 'public'
> mStyle ~~ 'm' indicates it is scoped to the class 'private'

Agreed.  Personally, I use a simplified version of the above:

m_var1  ~~ 'm_' indicates this is a non-public member variable sm_var2 ~~ 'sm_' indicates this is a non-public static member variable

And that's it.  For most of the rest I typically use namespaces in C++, so I suppose I'd use structs or some such in D.


Sean


June 01, 2005
Brad Beveridge wrote:
> David Medlock wrote:
> 
>> Regan Heath wrote:
>>
>>> http://joelonsoftware.com/articles/Wrong.html
>>> An article by "Joel Spolsky".
>>> I loved it.
>>>
>>> Regan
>>
>>
>>
>> His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
>>
>> His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
>>
>> -DavidM
> 
> Really, what it boils down to is "give your variables sensible names".
> D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
> 
> typedef int rowType;
> typedef int colType;
> 
> rowType r;
> colType t;
> 
> r = t; // D compiler will catch this.
> 
> So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be implicit.
> 
> Brad


Yes, but his point(and Raymond Chen's) is that you do not prefix based on  *scope* or *type* but usage.  I think this is more powerful than the others.  Really does it matter that a x coordinate is an int, or that is is a class or module variable? No, just that it represents screen coordinates.

-DavidM
June 01, 2005
Derek Parnell wrote:
> On Wed, 01 Jun 2005 14:45:19 -0600, Hasan Aljudy wrote:
> 
> 
>>Brad Beveridge wrote:
>>
>>>David Medlock wrote:
>>>
>>>
>>>>Regan Heath wrote:
>>>>
>>>>
>>>>>http://joelonsoftware.com/articles/Wrong.html
>>>>>An article by "Joel Spolsky".
>>>>>I loved it.
>>>>>
>>>>>Regan
>>>>
>>>>
>>>>
>>>>His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
>>>>
>>>>His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
>>>>
>>>>-DavidM
>>>
>>>Really, what it boils down to is "give your variables sensible names".
>>>D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
>>>
>>>typedef int rowType;
>>>typedef int colType;
>>>
>>>rowType r;
>>>colType t;
>>>
>>>r = t; // D compiler will catch this.
>>>
>>>So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be implicit.
>>>
>>>Brad
>>
>>Indeed, I think you only need something like hungarian notation is when you don't have strong types.
>>safe and unsafe strings should have different types, and the function that is used to retrive user input, should return it as an unsafe string.
>>This way, you wouldn't need to prefix variable names.
> 
> 
> I agree that a good type system caters for previous uses of Hungarian
> notation. However, I use prefixes on variable names to indicate scope. This serves the same premise that the author was promoting, namely that a
> person doesn't have to read a lot of code far from the current line to gain
> useful information about the variable.
> 
> Examples:
>  pText  ~~ 'p' indicates that this is a parameter passed to the function.
>  lScale ~~ 'l' indicates that this is scoped to the function or block.
>  vHigh  ~~ 'v' indicates it is scoped to the module
>  gRow   ~~ 'g' indicates it is globally scoped ie 'public'
>  mStyle ~~ 'm' indicates it is scoped to the class 'private'
> 

I sometimes prefix function parameters with p, specially when the name conflicts with a local name (or a member variable, if the function is a member function).

Type prefixes can server for easier readability sometimes, but I don't think it's really a good idea to use them for the purpose of "spotting bugs in my poorly structured code".
June 01, 2005
David Medlock wrote:
> Brad Beveridge wrote:
> 
>> David Medlock wrote:
>>
>>> Regan Heath wrote:
>>>
>>>> http://joelonsoftware.com/articles/Wrong.html
>>>> An article by "Joel Spolsky".
>>>> I loved it.
>>>>
>>>> Regan
>>>
>>>
>>>
>>>
>>> His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
>>>
>>> His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
>>>
>>> -DavidM
>>
>>
>> Really, what it boils down to is "give your variables sensible names".
>> D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
>>
>> typedef int rowType;
>> typedef int colType;
>>
>> rowType r;
>> colType t;
>>
>> r = t; // D compiler will catch this.
>>
>> So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be implicit.
>>
>> Brad
> 
> 
> 
> Yes, but his point(and Raymond Chen's) is that you do not prefix based on  *scope* or *type* but usage.  I think this is more powerful than the others.  Really does it matter that a x coordinate is an int, or that is is a class or module variable? No, just that it represents screen coordinates.
> 
> -DavidM

By variable usage, you mean "what it represents"? well, for me, that's a type (read: class).

What's the difference between

struct vector
{
    int x;
    int y;
}

and

struct dimension
{
    int width;
    int height;
}

there is no physical difference, but a conceptual one.

Off of my head, I'm guessing Joel Spolsky would use COORD to represent both, then prefix variable with
vec-
dim-


Is that "usage" or "type"?
I don't think there is a practical difference.
Different (or special) usage implies a new type to me.
June 02, 2005
Hasan Aljudy wrote:
> David Medlock wrote:
> 
>> Brad Beveridge wrote:
>>
>>> David Medlock wrote:
>>>
>>>> Regan Heath wrote:
>>>>
>>>>> http://joelonsoftware.com/articles/Wrong.html
>>>>> An article by "Joel Spolsky".
>>>>> I loved it.
>>>>>
>>>>> Regan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
>>>>
>>>> His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
>>>>
>>>> -DavidM
>>>
>>>
>>>
>>> Really, what it boils down to is "give your variables sensible names".
>>> D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
>>>
>>> typedef int rowType;
>>> typedef int colType;
>>>
>>> rowType r;
>>> colType t;
>>>
>>> r = t; // D compiler will catch this.
>>>
>>> So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be implicit.
>>>
>>> Brad
>>
>>
>>
>>
>> Yes, but his point(and Raymond Chen's) is that you do not prefix based on  *scope* or *type* but usage.  I think this is more powerful than the others.  Really does it matter that a x coordinate is an int, or that is is a class or module variable? No, just that it represents screen coordinates.
>>
>> -DavidM
> 
> 
> By variable usage, you mean "what it represents"? well, for me, that's a type (read: class).
> 
> What's the difference between
> 
> struct vector
> {
>     int x;
>     int y;
> }
> 
> and
> 
> struct dimension
> {
>     int width;
>     int height;
> }
> 
> there is no physical difference, but a conceptual one.
> 
> Off of my head, I'm guessing Joel Spolsky would use COORD to represent both, then prefix variable with
> vec-
> dim-
> 
> 
> Is that "usage" or "type"?
> I don't think there is a practical difference.
> Different (or special) usage implies a new type to me.

Actually he means *usage of a type*.  For his example he has 2 different kinds of strings that diff in their contents, but not their capabilities.  It would be pretty useless to make

class EncodedString {..}
class UnEncodedString {...}

just to make the point that one needs to be Encoded before it can be displayed on a web page.

Using your example, perhaps the width and height are floats, but represent the percentage of the parent window?  Sometimes they represent screen coordinates. Other times window coordinates. The same could apply for coordinate.  You _could_ make separate classes for this purpose, and write reams of code for conversions and whatnot(and with each page of code and interlocking methods your code becomes harder to maintain).

Or you could just use the conventions he talks about.

I think the gist of it is, when you rely on the type system too much perhaps you don't understand the flow of your program well enough and are prone to mistakes.

-DavidM
June 02, 2005
David Medlock wrote:
> Hasan Aljudy wrote:
> 
>> David Medlock wrote:
>>
>>> Brad Beveridge wrote:
>>>
>>>> David Medlock wrote:
>>>>
>>>>> Regan Heath wrote:
>>>>>
>>>>>> http://joelonsoftware.com/articles/Wrong.html
>>>>>> An article by "Joel Spolsky".
>>>>>> I loved it.
>>>>>>
>>>>>> Regan
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> His point with App-Hungarian notation is correct, that variable usage is more important than just a variable's type.
>>>>>
>>>>> His underlying theme( which I agree with 110% ) is that your programming  idioms are vastly more important than the underlying constructs used to implement them.
>>>>>
>>>>> -DavidM
>>>>
>>>>
>>>>
>>>>
>>>> Really, what it boils down to is "give your variables sensible names".
>>>> D has strict typedefs so you can create new types, which the compiler will complain about.  Ie, from his row/col example
>>>>
>>>> typedef int rowType;
>>>> typedef int colType;
>>>>
>>>> rowType r;
>>>> colType t;
>>>>
>>>> r = t; // D compiler will catch this.
>>>>
>>>> So, if you want to write truely robust code you can create a slew of new types to ensure that any conversion from type to type will not be implicit.
>>>>
>>>> Brad
>>>
>>>
>>>
>>>
>>>
>>> Yes, but his point(and Raymond Chen's) is that you do not prefix based on  *scope* or *type* but usage.  I think this is more powerful than the others.  Really does it matter that a x coordinate is an int, or that is is a class or module variable? No, just that it represents screen coordinates.
>>>
>>> -DavidM
>>
>>
>>
>> By variable usage, you mean "what it represents"? well, for me, that's a type (read: class).
>>
>> What's the difference between
>>
>> struct vector
>> {
>>     int x;
>>     int y;
>> }
>>
>> and
>>
>> struct dimension
>> {
>>     int width;
>>     int height;
>> }
>>
>> there is no physical difference, but a conceptual one.
>>
>> Off of my head, I'm guessing Joel Spolsky would use COORD to represent both, then prefix variable with
>> vec-
>> dim-
>>
>>
>> Is that "usage" or "type"?
>> I don't think there is a practical difference.
>> Different (or special) usage implies a new type to me.
> 
> 


> Actually he means *usage of a type*.
When you say that, you imply that type X could be used for purpose1 or purpose2.
If you're gonna use one type to represent different things, it'd be alot better to define X2 and use it for purpose2.

What's the difference between a wchar and an unsigned short? They're both numbers, and in the C family of languages, you can do things like
int a = 't';
so why would you use a "char"?


> Actually he means *usage of a type*.  For his example he has 2 different kinds of strings that diff in their contents, but not their capabilities.  It would be pretty useless to make
> 
> class EncodedString {..}
> class UnEncodedString {...}
> 
> just to make the point that one needs to be Encoded before it can be displayed on a web page.

Actually, you'd make something like a DefensiveString and subclass SafeString and UnsafeString from it. (read my other reply http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/24901)

Yes, there is a different behaviour for these strings .. it's not "just to make the point that one needs to be Encoded .....". It's to prevent the kind of bugs where you accidently print an unsafe string without encoding it first, hence opening yourself up for bugs. (read my other reply to understand what I mean).

> 
> Using your example, perhaps the width and height are floats, but represent the percentage of the parent window?  Sometimes they represent screen coordinates. Other times window coordinates. The same could apply for coordinate.  You _could_ make separate classes for this purpose, and write reams of code for conversions and whatnot(and with each page of code and interlocking methods your code becomes harder to maintain).

These examples are not necessarily different types of coordinates. They are still coordinates.
However, if in your program, there are different types of coordinates that need to be treated differently, then it'd be a good idea to subclass and redefine some behaviour for these coordinates.

> 
> Or you could just use the conventions he talks about.
> 
Or you could just use my methods. :P

> I think the gist of it is, when you rely on the type system too much perhaps you don't understand the flow of your program well enough and are prone to mistakes.

Actually, OOP is used to manage complexity, and it does it times better then the procedural way.

With his way, you can easily forget the rules and write

string sName = Request("Hello");

specially when you have so many such rules and the size of the project is too big.

With my way, you can't do anythign like

SafeString name = Request("Hello");

because the request function knows that user input is not safe, so it returns an UnsafeString.
And even if it did return just DefensiveString, polymorphism would take care of the line:

Print(name.getString()); //get string knows that name is unsafe, so it'll return it in an encoded form

where as with his way, you can easily write

Print(sName);

Niether you nor the compiler will see anything wrong with this.

and don't tell me that you can spot the error in "string sName = Request("Hello");", because you simply can't guarantee that. I mean, hell man, alot of us still make the mistake of doing
if( x = y )
and spend hours on end trying to find where the problem is without noticing this silly mistake.
You simply can't ensure that you can keep track of every rule you make for yourself and be able to ensure that every line of code complies to these rules.
June 03, 2005
Anders F Björklund schrieb:
> I didn't. :-)
> 
> Hungarian got a bad name by Microsoft's use of it, and is really a
> nice guy ? (despite his appearance)

He might have a point - sort of - though, as has been said often enough,
hungarian is pre-C++. In a typesafe language one would just declare his
own type, say, QuotedString, and only allow that to be printed into the
document. Anyway, a single example is only enough to dismiss, not to
prove an point.

> Exceptions and gotos are both bad, and error codes are much better.
> And all the extra idents makes it easier?

Oh, yes, and the most evil of all: continue and break. :) Oh, and while
we're at it: let's declare switch/case evil since it uses break so
often. :))) And premature ... [optimization? no! ej...? no!] ... RETURN
is a rppt pf sll 3v1L !!!

> They both remove me from the Quality Plateau, and distract. If it
> works for you, then follow it. Maybe we're different?

Software is complex today. What is appropriate if a simple program
fails? Do as if it succeeded? No! Rather bailout quickly and with an
error state. Exceptions are just that - they allow one to kill a
sub-program - particularly a part of an execution stack - up until a
higher-level, independant part of the program may discard that, perhaps
inform a user, and continue working. If a failure has occured, i don't
want that piece of code running any longer, tampering further with some
resource which has caused the failure. And that's what exceptions are
truly wonderful for. A code requiered to check global error state or
return values would often fail to do that correctly. Probably good and
correct exception-handling code is just as rare, but at least IT RETURNS
the control RELIABLY to the main program.

-eye
June 04, 2005
"Brad Beveridge" <brad@somewhere.net> wrote in message news:d7l58u$2fq5$1@digitaldaemon.com...

> Really, what it boils down to is "give your variables sensible names".

Agreed. You can invent some special naming convention. But why can't you just name your variables sufficiently well? Instead of "rwMax", you could write "rowMax" or "MaximumNumberOfRows".


If you are trying to say that something prefixed with "rw" should not be assigned to something prefixed with "col", then you may be talking about two different types and you should try to use the language to express them that way if possible rather than using identifier names as a poor man's type system.



I'm not necessarily saying that his style tip is bad. It's an extra layer of checking. But I'd rather not depend totally on human eyes to catch problems. That why we have computers.



In reading that article and a couple of the links it references, I again get that sense of Microsoft programming style that I get in their API design and sample code. Sometimes accomplishing anything takes many lines of code and several function calls. It's as if they are saying, "How do you create a widget you ask? You just call this sequence of 35 functions and voila! You're done! Easy. What's your problem?"  I'm sure they are very smart and can keep those long functions of procedural code in their head and it seems perfectly normal to them. Encapsulation is bad because it hides things; you should have everything in front of you so you know everything what's going on. I could be completely off-base about this, but based on the articles it seems like perhaps Spolsky and Chen think in a more procedural way rather than OOP.



Jim