🚀 go-pugleaf

In article <CJt6zI.45J@metronet.com> skip@metronet.com (Christopher Key) writes:

>   Please note, this is not a flame, but the problems I have with any naming
>   schema such as you are describing is that it places emphasis on the _type_
>   of an item instead of the _use_.  Unfortuneately, this is a religious
>   subject among programmers, so you aren't very likely to get much
>   intelligent discussion on the topic.

Well, quite often the implementation details require the use of some
particular type, regardless of it's use. For example, when using
X-Windows library functions or scanf it is very important that
variable types are exactly what is required. But I agree that it is also
very important to indicate the intended use of variables (see below).

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). 

>   As an example of what I am talking about, the most common area of
>   programming that I am familiar with that uses a schema like you are
>   describing is programming for microsoft windows, and IMHO the naming
>   conventions used are awful.  Most of the example programs you see have
>   variables with names like:
>
>     HWND hwnd;
>     char *lpszString;
>     HDC hDC;
>
>   These names are terrible (and yet names like these seem to be the norm). 
>   The people who write code with names like this think they have done the
>   people to come a service, but in reality I think that they have done a
>   great disservice.  I mean, I _know_ from the declaration that hwnd is a
>   window handle, but I have no clue what window it is a handle to.  Without
>   a naming schema like you are proposing I suggest that the names would have
>   looked more like:
>
>    HWND MainWindowHandle;
>    char *InputString;
>    HDC OutputDeviceContext;
>
>   Which to me would have been far more maintainable.  In a well-designed,
>   encapsulated application the type information in the name seems really
>   redundant, and no amount of name-massaging is going to help a
>   poorly-defined application.

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
the variable. Yes, it is bad programming practice to solely name
variables according their type, so why do it when you can take the
best from both worlds? The variables in Your example should be
named something like: 

    HWND hwndMainWindow;
    char *lpszInput;
    HDC hdcOutputContex;

...where programmer gives the meaning of the variables
("MainWindow","Input","OutputContext") while automatic name styler
fills in the type information ("hwnd","lpsz","hdc"). This kind of
naming style combines the implementation type that is needed when
using functions, and it also gives information what concept the
variable represents. 

************************************************************************
* IMNHO: Hungarian -like naming scheme must not replace other good     *
* programming conventions, it is to be used together with them.        *
************************************************************************

>   To me, a tool such as you are describing isn't going to be very useful
>   simply because it cannot control the important part of a variable name,
>   which is the mapping between the name and the usage.  With a modern
>   compiler, the type is usually unimportant, because the compiler should
>   catch the stupid mistakes that the visual type-checking provided by such a
>   schema provides.

A tool that would inspect the meaning of your code and name variables
according their usage would really be something, but I'm afraid that
will require some major breaktroughts in Artificial Intelligence
research. This automatic naming styler I am proposing is no
miracle-tool that will lift the quality of source code magically by
itself. It is a tool to help create and maintain source code that has a
familiar, coherent outlook, that is easy to read once you learn the
conventions used, and that gives some detailed information about the
(implementation of) identifiers.

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
warning or error does not mean that the code is otherwise correct
(I would die for a compiler that could prove the correctnes of
source code, or, even better, automaticly create the correct code for
me  :-) 

		Rami