🚀 go-pugleaf

In article <RJH.94Jan18222909@lk-hp-10.hut.fi> rjh@snakemail.hut.fi (Rami Juhani A H{nninen) writes:
>Types give much information about the use of variables, too. For
>example, to know whether an object is a string or a window tells us
>quite a lot about the variable (szMainWindow could be the name of the
>main window in our application, while hwndMainWindow would be the
>handle to it). 

In which case I would prever the names MainWindowName and MainWindowHandle,
respectively. Much more readable, and outside the abilities of the proposed
automatic tool. You cannot deduce from the type "char *" that the type
necessarily represents a name, but if your code normally handles names
using "char *", you can deduce the type from the name MainWindowName.

>The use of Hungarian style name encoding does in no way prevent the
>use of "good" variable names that describe the meaning and _use_ of

Yes, it hampers it. It leaves less space for describing the meaning.
And on the inevitable day you decide to change the representation, you
will have to change a lot of variable names.

Returning to the above example, assume that I decide to represent all
names in my program with a special UNICODE string type that is not at
all the same as "char *". I can do so without changing variables like
MainWindowName. They would still be appropriate.

In the corresponding situation, the consistent user of Hungarian naming
would have to look up every name that begins with "sz" and decide if it
is a name or if it still represents a zero-terminated char string.
No thanks.

...
>    HWND hwndMainWindow;
>    char *lpszInput;
           ----
If I recall correctly, "lpsz" is a "far pointer to zero-terminated
string", a concept that makes sense only on 16-bit PC:s. Thus this
variable name is not only representation-dependent, it is
machine-dependent! What do you do when you port the program?

>In other words, the goal is to increases the readability of source
>code. This is very important when the code was written by somebody else
>than youself, and you are trying to understand what the h*ll the code
>is supposed to do. The fact that the code compiles without a single

I fully support this goal, but hacking GCC to support it is futile
(and in any case, I hate the idea of putting features to GCC that are not
directly part of the job of efficiently and safely compiling programs,
FSF should not turn GCC into a Swiss Army Knife; they already have Emacs :-).
There is *no* mechanical substitute for the programmer's sense of good
style. So it is far better to direct your efforts towards improving it.
What is needed is education (involving good examples of the preferred
style of your project) and code reviews. I believe the important thing
is to get everybody involved to agree with the style, whatever it is
(if necessarily, modify it to gain consensus).

--
Erkki Ruohtula     / Nokia Telecommunications Oy
eru@tele.nokia.fi / P.O. Box 33 SF-02601 Espoo, Finland
(My private opinions, of course)