🚀 go-pugleaf

 
 	A New Feature in GCC: enforced naming style, part 2 (again long)
 	----------------------------------------------------------------

I sent an article about building a new gcc feature to enforce strict
naming styles to this newsgroup about a week ago. Although I tried to
make the article flameproof, I have received several answers that
flamed the idea. Also there have been some very good critisism and
ideas, that I will now try to sort out in this article. I also present
some arguments and opinions why an tool to enforce naming styles could
be valuable and useable addition to the "standard" collection of software
management tools.

I constantly write in IMHO -mode, so please don't think that I claim
that everything I write is absolutely true. Instead I try to offer
grounds and reasons why something I suggest might be reasonable. I
might be wrong, of course. Just prove it to me, please.

Although this second article is (again) long, please read it trough
before answering. I ask this because I got several flaming notes from
people who clearly had not read the whole previous article. Also,
please post your answers instead of mailing them, because I would
like to keep this discussion as open as possible.

(To the one person that mailed me a note claiming that USENET is not a
good media to presenting new ideas and discuss about them, but just a
place "to implement your idea and show that it's useful": I just
couldn't disagree with you more. Few good ideas emerge from one person
only, and a worldwide net of software and other gurus is THE BEST method
to evolve and test new ideas and see whether they are any good at all)

	Clarification: What is a naming style, what it is not?
	------------------------------------------------------

One of the main advantages of good naming style is that is instantly
gives some important information about an identifier. This same naming
convention idea have been in use in well written documents and
manuals for a long time. Open any good manual, and somewhere in the
beginning there is a table that describes the styles that are used to
mark different concepts. When I speak of a naming style, I mean
something similar than this, converted to suit the needs of a
programmer.

Several people that answered to the last article had mixed two totally
different concepts together: definition and style. A definition is an
accurate and exact desctiption of something, for example of a
variable.  It _defines_ the type and other properties of the object
the definition refers to. A style instead is a way to _name_ the
identifier, that is, a label to the object that is being defined. Style
is in no way indented to replace the definition of an object or carry
as much detailed information about the object as the definition does.
In other words, you can take some aspects from the definition and use
them to construct a identifier obeying some particular style, but you
can't (in general) take a variable name and extract enought
information from that to be able to define the variable.

* Also, it is very important to notice that it must be possible to
* change the style without changing the meaning of source code. To give
* a simplistic example, changing document font (style) must not change
* the meaning of the text (definition).

	Everybody uses some style
	-------------------------

To those people who think that name style is just additional burden
that they will never need or use, I argue that every programmer uses
at lease _some_ style. For example, if you write all you identifiers
with small caps without any pre- or postfix -strings, isn't that a
"style"? You very carefully not write a prefix to each identifier. You
very carefully write all identifiers using small caps. If you for some 
reason accidentaly write an uppercase letter or prefixing underscore
to some identifier and you notice it later, don't you fix it to obey
the _style_ you are using? If you are using uppercase letters for macro
names, well, that is just a bit more complex style based on identifier
class (macros and non-macros).

My point is that _everybody_ uses styles. Some styles are just more
complex than others. A cOde __w_ritteN C_oM_ple teLY wITHoU_t __ANy_
_s_t_y_l_e_ would bE HOrrIbl_e. 

	Style based on type introduces redundant information?
	----------------------------------------------------

Several people claimed that naming variables according the type and
other properties introduces unneccessery information into the source
code and they considered this as a "bad thing". And this is true,
naming by type encodes information into the identifiers that could be
retrieved from somewhere else. This information may be unrelevant to
the compiler, but it is not unrelevant to the programmer.

The problem is of course to keep this extra information consistent
with the actual definition, and that's why we need the style checker.

Why then the programmer just can't check the definition of the
identifier to see what it really is? There are tools to find
identifier definitions (ctags, grep) and there are handy editor key
combinations that change the current view -window to the beginning 
of the function where the definitions lie. One argument was that
a good programmer always keeps the definition and use of identifiers
close to each other, but this really is not always possible.

All that I can say to this is that there is no faster method to
retrieve information about an identifier than to check it's name and
interpret the information the naming style encodes. Also if the style
is "well defined", style encodes only the "relevant" information thus
highlighting the important properties of the identifier. And, you
just can't use use 'etags' or 'M-x-find-definition' with source code
printed on paper. (Try it if you don't belive me :-).

	What information the name style should encode?
	----------------------------------------------

Some answers rightfully brought up the question what information the
name style should encode. Using for example 'dVariable' to indicate
that 'Variable' was defined as double is helpfull, but actually it is
an implementation detail that real-software-engineers will find
disturbing and irrelevant information. A "better" encoding style would
indicate that 'Variable' is a floating point variable, or even better,
a variable that has a value of some well defined concept like
'Temperature' or 'Velocity'. A powerfull enought style description
language should give programmers the possibility to use their own types
to define identifier styles.

There are also other important concepts besides the identifier type
that could and should be encoded into identifiers. Identifier scope
(local, global, module or class wide global), reference type (value,
pointer, array, handle), "constness" (constant or not) and memory
allocation (dynamic, automatic, static) are always good things to know
about. Thease properties are sometimes purely implementation issues,
but - believe it or not - some programs are actually implemented using
some computer language, and thease programs are then later debugged and
developed. I know. My friends have told me.

	Who's style will it be? Yours, mine or committee's?
	---------------------------------------------------

I suppose we all agree that there is no single naming style that would
meet all the needs and different tastes programmers have. So, the
style must be freely defineable for this tool to be widely acceptable.
Now, what does this really mean? 

We must have a formal way to define how to construct a identifier name
given identifier definition and it's "basename". Some kind of ruleset
is needed to define the relationships. To be able to change the style
later it is required that the "basename" of an identifier can always
be extracted from the "styled" name.

The full description language may be very difficult to define, but
perhaps it could be something like the following. Please note
carefully that this is _just_ an _example_ of one possible set of
rules and the syntax and grouping of the rules is almost certain to be
incomplete. (So many of you thought last time that the syntax I
presented as an example was to be the one-and-only, holy and high, the
true style everyone should obey. No. I just use the style for now, so
it was natural to present it as an example.)

Class translation table

	typedef		-->	T
	struct		-->	S
	union		-->	U
	enum		-->	E
	 :		 :	:
	class		-->	C
	
Type translation table:

	double		-->	d
	float		-->	f
	short		-->	s
	mytype1		-->	mt1
	money		-->	$
	warehouseitem	-->	whi
	 :		 :	 :
	display		-->	dis

Scope translation table

	global		-->	G
	module		-->	L
	member		-->	M
	 :		 :	 :
	local		-->	<nothing>

Allocation translation table

	automatic	-->	<nothing>
	static		-->	S
	 :		 :	 :
	dynamic		-->	D

Reference type translation table

	value		-->	<nothing>
	pointer		-->	p
	handle		-->	pp
	array		-->	a
	2-dim array	-->	aa
	 :		 :	 :
	implisit	-->	<nothing>

Case translation table:

	constant	-->	upper
	macro		-->	upper
	local		-->	lower
	 :		 :	 :
	member		-->	no change

Identifier name construction table

	global & constant	-->	(Scope)C_(BaseName)
	local			-->	(Type)(Reference)(BaseName)
	 :			 :	 :
	typedefinition		-->	(Class)(BaseName)


	Implementing the style checker
	------------------------------

I was particularly strongly flamed about the idea of integrating the
style checker into the compiler ("braindead idea, etc."). As it was
pointed out by some answers, the style check would have to be
implemented into both to the preprocessor and compiler, making it a
difficult task.

What I ment was that the style checker should...er,no...it would be nice
if the style check would be carried out during some stage of the
compilation process. This would help keeping the identifier names
consistent and "on-line". Running separate checks like 'lint' is
always clumsy.

(BTW, Although 'lint' is a very handy program, the very existence of
lint is due the fact that C-language is incomplete, difficult,
dangerous and non-software-development-friendly language. I have
switched to C++ about a year ago, and even if there are some problems
with C++, the fact that there is no need for 'lint' with C++ (when
using a "good" C++ compiler) suggests that C++ (and also Ansi-C) is big
step to the right direction :-)

Actually we would need two tools: one like 'C-beatifier' or 'lint'
that takes as an input a set of source files and style definitions and
formats the source files to obey the defined name style (and, if
possible, would reindent the source files). Once the source code obeys
the given style, another tool, run during the compilation process
could be used to maintain the naming style coherent. Whether the
second tools is build into the compiler/preprosessor or it is a
separate program, or whether it is run parallel/before/instead of the
compiler, that I leave to the implementor to decide. These two tools
could also be integrated, of course.

The main difference between these two tools would be that the first
one modifiers the source code (or outputs the modified source to some
other file than the original) while the second tool just produces
warnings messages of name style violations. With the first tool, you
move from one style to another (for example "strip" the style from the
code, which is just another style), with the second tool, you manage the
source code and keep it consistent.

	Who will do it?
	---------------

Yes, who will do it? Not me, not at least now. My knowledge about
compiler technology is limited to using it, not designing it. Lex and
Yacc and Bison are mystery programs for me at this time. I'm not
claiming that style checker is the most important new feature that
should be implemented right now, or that You, my dear reader, must
immediadly start coding it. I am suggesting that someone who thinks
that there is something in this idea could collect credits and merits
by implementing it. Or, perhaps after 60 years when my working career
is (hopefully) over, or when my daily 15 min. average workload drops
under 1.0, I will finally have the time and the skill to do it myself ;-)

And let's keep this second round on reasonable discussion level, OK?
(I do not for example even smoke tobacco, and I am not braindead...I think.)






		Rami