Weblogs Forum - Style is Substance

Articles |
News |
Weblogs |
Books |
Forums

Artima Forums | Articles | Weblogs | Java Answers | News

Sponsored Link •

Weblogs Forum
Style is Substance

44 replies on 3 pages. Most recent reply: Oct 28, 2012 11:43 AM by Hans Scundal

Welcome Guest
Sign In

Back to Topic List

Reply to this Topic

Search Forum

Threaded View


Previous Topic		Next Topic

Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 | » ]

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

This is a silly idea

Posted: Oct 7, 2004 3:56 PM

if for no other reason than my coding conventions are the best and the ones selected by the people publishing books are crap (largely because they are trying to not waste paper).

I format code so I can read it. I like

lots

of

white

space

and I need things (like braces) to
line
up
vertically
because of a visual processing disability.

So I don't think much of your proposal.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Style is Substance

Posted: Oct 7, 2004 6:27 PM

> re the main post ... my main problem with layout standards
> is that they are indirectly a constraint on the whole
> development environment of the programmer. A standard
> which is right for a 21 inch desktop may not be right for
> a 15 inch laptop. Maybe I prefer to split my Emacs window
> vertically and you prefer to split it horizontally.
>
Along the same lines (so to speak), another use case that could be threatened by a layout standard is publishing code in books and articles. The lines of code I write that actually runs are invariably longer than the ones I write to display in an article. So it seems that somehow that the standard would need to be flexible about line length.

Matthew Wilson

Posts: 145
Nickname: bigboy
Registered: Jun, 2004

Re: Style is Substance

Posted: Oct 9, 2004 1:21 AM

Well intended, but dead wrong for three reasons, in increasing order of import:

1. It ignores human nature. If C forces me to use K&R bracing, I'm going to stop programming in C. Sure, it's stupid, petulant, <myriad pejorative adjectives injected here>, but it's cold hard fact. That's not to say that I flout coding conventions when working for my paying clients, but that's a different matter from a programming language forcing me.

2. It's not necessary. If any person/organisation truly cares that much, they can arrange for (de-)pretty-printing before/after check in/out.

3. Either (i) you assume that whatever-your-C-prescribed-style is, it is suitable and good for all languages, or (ii) you actually think that it's a good idea for heterogeneous code bases to have styles that differ on a per-language basis arbitrarily. I don't, and I've never worked with/for anyone that does.

Cheers

Matthew

Mike Spille

Posts: 25
Nickname: mspille
Registered: Nov, 2002

Re: Style is Substance

Posted: Oct 9, 2004 4:37 PM

Rick Kitts probably said it most succinctly, but I'll take a stab at it.

Programming languages and code exist for humans to write and read. They exist for programmers to express their intent. A computer does not execute your Java/C#/C/C++/Perl/whatever code - it gets translated from a human-palatable form into a machine palatable form. So, to put it simply, computer languages exist for human readability and writability. Source code is a form of creative expression. Yes, it's a form which is constrained by reality (a computer _does_ have to execute the damn thing unambiguously, after all) but beyond these very necessary constraints the programmer is allowed to express his intent as he wishes. The formatting of code is not there to make the compiler/computer happy - it's there to convey the programmer's intent to other programmers.

The plain fact is that a rigid syntax definition will mean that certain points will be impossible to convey in source code - the language will disallow this for no practical reason what so ever. Worse, any such mandated syntax will get certain subtlies wrong - it is guaranteed that the person or persons standardizing it will get some things wrong, and it will be very difficult if not impossible to change it after the fact. And what will kill people is that someone will be attempting to force them to live with some mis applied constraint _that has no rationale behind it_.

People live with ugliness and constraints when there is a practical reason behind it. In languages, it usually boils down to unambiguity or speed. We live with syntax constraints because it keeps the language simple, or makes the compilers less buggy, or it makes compiles run faster. But most programmers will not live with a set of arbitrary constraints whose only basis is aesthetics.

Bill Venners

Posts: 2284
Nickname: bv
Registered: Jan, 2002

Re: Style is Substance

Posted: Oct 10, 2004 3:32 PM

The article Phil pointed to at:

http://www.third-bit.com/~gvwilson/xmlprog.html

is pretty much talking about exactly the same notion I got out of learning about Gosling's Jackpot project. However, I have one major bone to pick: the author, Dr. Gregory V. Wilson, suggests the "model" be stored in XML. Blech. Why not store it in something that people want to actually program in, like Ken's idea of a language with very rigid style rules? That way people could look at it, read it, and edit it directly when they needed to (or wanted to), but an IDE could also present that program in whatever style the reader/writer prefers. People who use such IDEs would be dealing with a "view" of the program.

Michael Feathers

Posts: 448
Nickname: mfeathers
Registered: Jul, 2003

Re: Style is Substance

Posted: Oct 10, 2004 3:43 PM

> The article Phil pointed to at:
>
> http://www.third-bit.com/~gvwilson/xmlprog.html
>
> is pretty much talking about exactly the same notion I got
> out of learning about Gosling's Jackpot project. However,
> I have one major bone to pick: the author, Dr. Gregory V.
> Wilson, suggests the "model" be stored in XML. Blech. Why
> not store it in something that people want to actually
> program in, like Ken's idea of a language with very rigid
> style rules? That way people could look at it, read it,
> and edit it directly when they needed to (or wanted to),
> but an IDE could also present that program in whatever
> style the reader/writer prefers. People who use such IDEs
> would be dealing with a "view" of the program.

Sounds a lot like Charles Simonyi's Intentional Programming too. For a long while I wanted to learn about it but it has been years and it doesn't seem that much has happened beyond the spin-off from Microsoft.

Bruno Ranschaert

Posts: 1
Nickname: brunor
Registered: Oct, 2004

Re: Style is Substance

Posted: Oct 12, 2004 6:14 AM

I do not agree with the thesis that formatting rules should be part of the programming language.

In the early days programmers had to punch holes in fixed locations in cards in order to express the algorithm. Later on, programmers had to write statements in fixed locations on the screen (RPG). Advances in compiler technology made it possible to concentrate on the concepts, not on the formatting or punching. I do not want to go back to that era where programming was equal to tedious typing in characters at a keyboard.

Formatting code is a management issue, not a programming issue. Formatted code is not better than unformatted code. There are arguments in favour of code formatting in large organizations with lots of people working on the code. It is
wrong to generalize this situation. In this case, you can use code formatters, the organization can choose the format.

Formatting code is a subjective matter, there is not foundation to make rational decisions about how to format.

Programming is problem solving, the programming language is a tool to express the algorithm. Fixed formatting
rules do not help writing code.

Brian Pontarelli

Posts: 5
Nickname: brokenwren
Registered: Oct, 2004

Re: Style is Substance

Posted: Oct 12, 2004 7:10 AM

No, please don't ever make these part of the language specification or the compiler. Coding standards are the lamest discussion I've ever taken part in.

Here's a little story. First job out of college. I freak out on all 3 of my fellow programmers because no one is following coding standards. I want hungarian notation and strict formatting with tabs, etc. etc. We come together and make some standards and we all follow them. Then, the company goes big. We hire 20 new people and everyone starts coding. We make sure to tell all the new developers about our coding standards and we even try to enforce them a bit. But guess what, it doesn't work and for that matter it some people take it personally. I quickly learned that coding style is something very unique to different people.

I have a 4 page document on my personal coding standards and I always do things identical for every class I write. I even force myself to javadoc EVERYTHING. But guess what... If I forced some other developer to conform to my standards, they'd probably end up setting fire to their computer, killing me, and then killing themselves. The reason being that they don't work well with my standards. They have their own asthetic that when they code makes them feel all warm and fuzzy. Now they are forced to code in a style that everytime they do it, they get more and more pissed off, because to them it seems completely stupid.

Here's another example. One place I worked had a set of coding standards. They said, "all class variables must start with an underscore." My first thought was, "Oh man! Underscores are ugly little characters that should be banned from existance. Even Sun suggests that underscores be avoided like the plague." So, I either suck it up and write the litte "_" before all my variable names, hate coding and sub-consciously end up producing bad code really slowly in a junvenile passive agressive ploy, or I just code like I do.

Here's my conclusion. If you are not able to see around coding style and read the actual code, well, you probably shouldn't be coding. Likewise, if you have coding standards and any one single person says, "these things suck!", then your standards are probably to strict and you need to burn them or loosen them (I prefer burning). Okay, so here's my philosophy: If you write the code, do it however you want. Feel free. But when you are reading someone elses, or even fixing it up a bit, please be a grown up and don't rewrite the entire class because they don't use your style. Learn to read the code not the style and you'll be a happier more well balanced person.

I particularly like the thread about code views. I think that in order to make these practical, the code should be stored without any whitespace except that necessary to enforce language syntax. This way it can always be reduced to the same version no matter what. The problem is that every IDE, editor and line printing program needs to be updated to support the viewer (I like to call it a code-lense). Not likely, so, I fall back to my earlier ranting and raving.

Cay Horstmann

Posts: 13
Nickname: cay
Registered: Apr, 2003

Re: Style is Substance

Posted: Oct 12, 2004 8:00 AM

Ken writes: "For almost any mature language, coding style is an essentially solved problem", and then goes on to advocate that the C compiler enforces the K & R style.

However, as we know from C++ and Java, changes to the language that breaks existing code are not likely to happen if there is a feasible alternative.

That's why we have for (x : xs) rather than for (x in xs) in Java and class Sub : Super rather than class Sub extends Super in C++.

The right place to dictate a coding style is with an immature language. Guido van Rossum points out that Python has essentially no issues with coding style because the use of whitespace for block nesting forces a uniform layout. Algol 60--the language that was a great improvement over so many of its successors--had a presentation style with typesetting rules!

Cheers,

Cay

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

What is old is new again

Posted: Oct 14, 2004 12:51 PM

> This is the image I got when talking to Gosling about his
> project Jackpot, in which the notion of program truth is
> not text, but an annotated parse tree--something that was
> traditionally not built until the compiler compiles.

It's better to have a true abstract syntax tree rather than a simplistic parse tree.

> But
> Gosling wanted to see what kind of things he could do if
> the IDE kept everything in a parse tree form, and he was
> able to do some visualization and refactoring stuff. The
> refactoring sounded like what IntelliJ had been doing for
> quite a while, but the really interesting conceptual leap
> I got from the conversation was that maybe future
> languages could be defined not as a text syntax but as
> some kind of data structure.

This is how Lisp was originally created.

John D. Mitchell

Posts: 244
Nickname: johnm
Registered: Apr, 2003

Implicit and Tacit information in Code Formatting

Posted: Oct 15, 2004 8:00 AM

This came up in a recent thread (http://forums.java.net/jive/thread.jspa?threadID=40&tstart=0) in the java.net bookclub discussion of Paul Graham's Hackers and Painters (http://forums.java.net/jive/forum.jspa?forumID=21).

Mikael Grev

Posts: 1
Nickname: mgrev
Registered: Oct, 2004

Re: Style is Substance

Posted: Oct 15, 2004 10:20 PM

You are correct about one thing, code style is a pain in the *ss! Your solution however I'm no fan of. Why not create an XML dialect instead, and propose it as a standad? Then any IDE with respect could read/write it and understand what it means without using complex regex statements. For insance:

<code>
<if>
<expression>
<vaiable>a</vaiable>
<operation>=</operation>
<vaiable>b</vaiable>
</expression>
<if>
<code>

or whatever. Then every IDE can present the code in any style. One developer can code in one style and another one will read it using another style. Perfect. As long as the XML is good an flexible it could probably be used for any language, in fact, it should be TOTALLY language neutral and if some code segment can't be broken down it can simply be contained in it's native format.

Codeing style transformes could be standard as well, so that a new developer can simply choose a standard style to start with without having to set those 19321 setting him/her self.

Portability wouldn't be a problem, all IDE's should be required to output normal source as well, possibly within the XML itself. And reading XML and transforming it is done in a couple of lines of code nowadays.

Now THIS is possible, and would be SO great. IMHO of course.

Cheers,
Mikael Grev

Mats Henricson

Posts: 55
Nickname: matsh
Registered: May, 2003

Re: Style is Substance

Posted: Oct 18, 2004 2:09 PM

Just wrote about this on my blog:

http://www.jroller.com/page/matsh/20041018#style_is_symmetry_and_structure

J Alan Brogan

Posts: 1
Nickname: jalanb
Registered: Jun, 2005

Re: Style is Substance

Posted: Jun 24, 2005 4:53 AM

I disagree completely.

I agree with Premise 1 & 2.

Premise 3 - true, but so what ?
a) sourceforge.net purty printers are programs written in people's spare time - who are we to say what should/not be done ? It may be a superfluous problem, but it is nonetheless an interesting one, and once they exist they allow more mature coders to leave the style wars behind.
b) VCS resources - Duh ! That's what they are for. If you are so worried about the space taken in history logs, perhaps you shouldn't be using a VCS at all ?
c) Brain cycles are only wasted in style wars (ako flame war), which again is kinda: Duh ! That's what flame wars are for: to burn off the extra energy adolescents are "blessed" with.

Premise 4 is not quite true, and hence the first 3 premises are more correctly adressed by going away and finding some interesting problem to worry about.

Premise 4 is not quite true: while it is "pretty well agreed on", there is no evidence that it is true. Have you ever compared a project which was developed using one coding style, with the same project using many coding styles ? How do you compare the "pain" of the constraints of one style on all team members (NOT one person) with the "pain" of conflicting styles.

What *is* the pain of conflicting styles ? When was the last time you read some code where the style was so bad, that the rest of the code wasn't just as bad ?

IME no-one spends 5% of the time on coding style issues - they are too irredemiably trivial. Even with the qualification of "mostly up front" that is still a gross over-estimation. And I have *never* heard any coder raise the issue in the real world, only managers / QA people. Some coders ("mostly up front" of their coding careers) may shout about it on usenet, but at work they are either too junior to raise it as an issue, or too senior to take it seriously.

And, of course, the real reason this article is merely a troll: because style issues are so trivial, *any* argument about them is only of interest to less mature "debaters", and so *any* argument about them is undecidable. Why do you think the committees who write standards should be any less likely to degenerate into interminable style wars ?

Chris Nandor

Posts: 2
Nickname: pudge
Registered: Jun, 2005

Re: Style is Substance

Posted: Jun 27, 2005 9:12 AM

Premise 1: For any given hardware, there are one or a few common coding operating systems.
Premise 2: There is not now, nor will there ever be, an operating system whose benefit is significantly greater than any of the common operating systems.
Premise 3: Approximately a gaboozillion cycles are spent on dealing with OS variations.
Premise 4: For any non-trivial project, a common OS is a good thing.
Conclusion: Thinking of all the code in the entire world as a single "project" with a single OS, we would get more value than we do by allowing for variations in style.

Premise 1: For any given OS, there are one or a few common coding languages.
Premise 2: There is not now, nor will there ever be, a programming language whose benefit is significantly greater than any of the common languages.
Premise 3: Approximately a gaboozillion cycles are spent on dealing with language variations.
Premise 4: For any non-trivial project, a common language is a good thing.
Conclusion: Thinking of all the code in the entire world as a single "project" with a single language, we would get more value than we do by allowing for variations in style.

And so on. This is really an intensely silly idea.

Flat View: This topic has 44 replies on 3 pages [ « | 1 2 3 | » ]

Previous Topic

Next Topic