Enforce the style guide!

When I was reading about a new programming language I became very
enthusiastic.
Then I noticed that the compiler would not enforce the style guide. This was
a disappointment for me. Here was a language that was trying to be the best
language for programming. A language to make it easy for the programmer with
only clear rules. A language that does not make the mistakes that other
languages have made. But not enforcing a style guide is a mistake.
The most useless and time-consuming discussions about C and C++ are about
the style guide. There are dozens of style guides with even more
interpretations of those style guides.

Let's try to explain.

The next quote you can find on the official D programming site:
"The D Style is not enforced by the compiler, it is purely cosmetic and a
matter of choice. "
This is only true for the designer of the language. It is not true for the
users of the language.
Style guide is not purely cosmetic. It is a way of defensive programming. It
prevents mistakes, with a fixed style guide the compiler can and will help
you. It is much easier to find bugs in a program that is written with your
style guide. And it is more effective to write always with the same style
guide. It is easier to find something, it is easier to read something.
Because it is a matter of choice, the designer of the language can make that
choice. He has to make that choice!

I think that the reason not to enforce the style guide is a marketing
reason! People will accept the language easier because it can look like the
language they are used to program in.
This looks nice in the beginning but will be horrible in the end. There are
several books about C and/or C++ style guides. Why? Why should I learn a
book about a style guide? I have learned the language already! For example
when I move to a different company, why should I learn a different style
guide? The compiler is the same, the language is the same and I am the same.
why, because there are other people with a different opinion. I will bet
that if those people had worked with a different company they will have a
different style guide.
Learn a style guide only once!

An argument could be that you learn a language easier if you use the same
style guide for both. But if the languages differ from each other, and they
do, the style guide could only come close.
Every language needs one and only one style guide.

I you think about all the benefits an enforced style guide has:
- Code editor support for style guide will be available. If you make a
mistake, the editor can correct you.
- Code completion will be easy to support.
- Extern written libraries, components etc. will be written in the exact
same style guide. If you buy or share a library with other companies then
the style guide is always the same.
- No code beautifier tools are necessary. You will not have to use code
beautifiers, because the style is already correct.
- Easy generated help files with the comments of the classes
- Easy code generation (in the correct style) with design tools. (UML)


I hope that you all agree that an enforced style guide is better for the D programmers' community. When we decide to enforce the style guide then the difficult part comes.

First of all we have to think about what the style guide can support and why
I should support that.
The next list is far from complete, but it is a start.
- The position of comments. (before/inside classes and methods). Prevents
different styles.
- Standard prefixing modules, variables, classes etc. Prevents different
styles. Prevents mistakes.
- The amount of white space between statements and within statements.
Prevents different styles.
- Enforcing 80 characters on a line. Easy to read and easy to print on
paper.
- One class per file. Prevents to many classes in one file.
- Coloring keywords. The style guide determines the colors. Easy to read the
code.
- Files with fixed filenames (the name of the class is the filename). Easy
to find the code.
- Use of capitals. Prevents different styles. Is easy to read.

After that we have to decide what will be in the style guide and what not. And that will not be easy.

For now I hope that you will think about an enforced style guide and maybe you will agree. I hope that the designers of this language will reconsider their choice for the style guide. It will be a lot of work for them, but think about this.  The style guide is for the programmers!


Harm van Dinter

Your comments are right on target as to why style guides are useful and necessary. But I've been through the style wars, and they are unwinnable <g>. It's best to let people program the way they want to.

But if they do want a style guide, providing a common one makes a lot of sense.

Walter wrote:

> Your comments are right on target as to why style guides are useful and necessary. But I've been through the style wars, and they are unwinnable <g>. It's best to let people program the way they want to.
>
> But if they do want a style guide, providing a common one makes a lot of sense.

Perhaps some sort of combination of XML and D could allow you to specify style guides?  I mean really, D source code is just a structured document...maybe somebody could write a utility that parses the D, looks at a style sheet of some sort, and produces "pretty" output.

--
The Villagers are Online! http://villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

While I agree that style guides are nice and all, from the average programmer's perspective, it's a total loser of an issue.  It might cut down on bugs in the long run, but basically, if I can only write something one way, then I'd better have total IDE support, or I'll spend more time chasing syntax errors in my formatting of the code than I'll save with everything being nicely structured and styled by fiat from on high.  I agree with Walter.  Style wars are unwinable, and no one is really going to be interested in something that limits them so much as the system that you describe.


Evan

"Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3DAB9E54.642C8DA4@deming-os.org...
> Perhaps some sort of combination of XML and D could allow you to specify style guides?  I mean really, D source code is just a structured document...maybe somebody could write a utility that parses the D, looks
at
> a style sheet of some sort, and produces "pretty" output.

Well it's done for lots of other languages in the IDE so I don't see why not D.

PS - When I get some time I may consider writing up a D IDE (from scratch) to bring all these tools together + other features.  I have some experience in the IDE area. But no promises.

"anderson" <anderson@firestar.com.au> wrote in message news:aogqv7$2jkl$1@digitaldaemon.com...
> "Russ Lewis" <spamhole-2001-07-16@deming-os.org> wrote in message news:3DAB9E54.642C8DA4@deming-os.org...
> > Perhaps some sort of combination of XML and D could allow you to specify style guides?  I mean really, D source code is just a structured document...maybe somebody could write a utility that parses the D, looks
> at
> > a style sheet of some sort, and produces "pretty" output.
> Well it's done for lots of other languages in the IDE so I don't see why
not
> D.

I see a style guide as much more than formatting. Doing a pretty-printer (source code reformatting) should be easy to do with D, since it is easy to lex & parse.

> PS - When I get some time I may consider writing up a D IDE (from scratch) to bring all these tools together + other features.  I have some
experience
> in the IDE area. But no promises.

It would be great if you could build one!

> I see a style guide as much more than formatting. Doing a pretty-printer (source code reformatting) should be easy to do with D, since it is easy
to
> lex & parse.

Your right.  I think style guides should be broken into two sections: Syntaxical and semantical (are they real words?).  The original writer of this thread was talking about the syntax side of things.  It would be next to impossible to do all semantical style checking automatically.

> > PS - When I get some time I may consider writing up a D IDE (from
scratch)
> > to bring all these tools together + other features.  I have some
> experience
> > in the IDE area. But no promises.
>
> It would be great if you could build one!

If I ever get on top of my other must do projects (and a few of my
want-to-do's) I'll give it a shot (and thats very likely (sarcasm)).

maybe the compiler could detect the use of hungarian notation and refuse to compile or even better delete the users file, since they have no clue what the term "abstraction" means

   :)

It is a good idea to break the style guide in two parts. The syntax of the language has my main focus. I hope that other people come up with good ideas to check the semantics.

Many people have a bad feeling about an enforced style guide and they see
only a lot of limitations for them selves. They are afraid of the compiler.
It will find all their little differences with the style guide. And they are
even more worried for a style war.
In my opinion we (the ones that are in favor of one style guide) will always
lose the style war because we have to defend our choice for one style guide.
(Our style guide will always be different from one of the opponents) We are
the ones that have to write code beautifiers for a language.
When a language enforces a style guide this will be all different, because
they have to defend their choice to introduce a different style guide. They
are the ones who have to build their programs to convert their 'language'.
They have to explain why they put so many efforts in something that is
basically the same.

Do not see a style guide as a limitation. See it as a choice that is already
made for you. It is a time saver! (For companies it is a money saver)
An enforced style guide will cause some extra bugs the first day you use it,
but after that you will get used to it. It is the same with changing a
language. When you are used to program in Delphi and you switch to C++ you
will get some errors because they have a different syntax. After some days
you are used to it. The advantage with an enforced style guide is that the
compiler will help you to trace these bugs. This is not the case with an
additional style guide that is used in your company. An IDE that helps you
with the style guide is recommended. Most IDE's have some kind of syntax
support. (Making keywords bold, change the color of numbers, keyword and
comments) Maybe the IDE for D could be more advanced and use something like
the grammar checking of Word. It could be a real-time checker that marks
pieces of code with a syntax error. With a strict style guide it should be
easy for the IDE to comment what is wrong. (In some cases the IDE can
correct the mistake by itself.)

Maybe these questions can help you to think about the advantages (and
disadvantages) of an enforced style guide.
Do I use a style guide now?
How much time did it cost me to learn it?
Do I use always the same style guide?
Have I used always the same style guide?
Who or what is checking the style guide, and how often?
Did I design my own style guide? How much time did it cost me?
Did I buy a book about a style guide? How much did it cost me? Do I use it
completely?
Do I copy code from other sources and am I satisfied with the style guide it
is written in?
Do I use a tool to help me with the style guide?
Somebody is already using a style guide, why do I need a different style
guide?

Please open your mind for new ideas. Look with a positive attitude to this idea. Try to imagine the benefits. And if you see a disadvantage, try to see whether or not it is a disadvantage, or just a different way of doing things. In all the comments on my article there was no real showstopper for an enforced style guide. But there were some negative sentiments, and the arguments used were opinions.  People react very emotional when it comes to style guides. It is almost like a very personal thing.


Harm van Dinter

And yes, Hungarian notation will trigger the alarm inside the IDE :-)