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 ]

Matt Gerrans

Posts: 1153
Nickname: matt
Registered: Feb, 2002

Re: Style is Substance

Posted: Jun 28, 2005 9:57 AM

intensely silly? ...that just doesn't sound right to me.

Jeff Szuhay

Posts: 1
Nickname: jeffszuhay
Registered: Jun, 2005

Re: Style is Substance

Posted: Jun 29, 2005 12:49 PM

I agree mostly but you left out the idea that style should reinforce the language design principles. A space aftear if, while, for, for example, violated the language design.

I prefer no space after control structure reserved words and
spaces after/before expression, block delimiters

if(a,b) // no spaces anywhere... makes me squint

if( a , b ) // preferred style.

in this case if( ... ) while( ... ) for( ... ) are really no different than a user defined function definttion. The pattern between all of them is the same.

And in the case of space comma space, the separator is delineating <expressioins> or <statements> or <parameters>.

Yep, its a bit breezy but entirely workable.

Chris Nandor

Posts: 2
Nickname: pudge
Registered: Jun, 2005

Re: Style is Substance

Posted: Jun 30, 2005 10:15 PM

"intensely silly? ...that just doesn't sound right to me."

Which only highlights how bad the idea is!

Lyndon

Posts: 2
Nickname: include123
Registered: May, 2003

Re: Style is Substance

Posted: Aug 31, 2005 6:18 PM

Text as a format for storing programming logic is an idea of the past.

Native storage of AST's is the future, let the programmer view
in a format of choice, but the logic is the same regardless.

Imagine a SCCS based on AST!!!. No more file level locking/merging. We could lock at the method/statement level. See revisions at the method/statement level...

Jon Strayer

Posts: 10
Nickname: jstrayer
Registered: Sep, 2003

Re: Style is Substance

Posted: Sep 7, 2005 8:47 AM

> Is this just the first step towards a standard IDE and
> computer? Are they gonna try to take Emacs away from me?

Of course. You should be using vi anyway. :-)

Vladimir Nesov

Posts: 27
Nickname: robotact
Registered: Aug, 2005

Re: Style is Substance

Posted: Sep 8, 2005 7:18 AM

> And most of all: <em>No More Style Wars!</em> Really!
> Think of all those cycles that we could then plow into something
> more productive, like vi/emacs wars! Or world peace! Or a
> <em>really</em> good chocolate cookie recipe! You choose!
Is it proposition to join Empire forces?

> Of course, you will never enforce any style globally
> unless people have literally no choice.
For greater good...

Most of the cases when style really matters (that is, something is written in a way you have major difficulties trying to understand the code) can't be solved by simple syntax level enforcing. It doesn't mean code in such cases is bad code: it can be converted too much more readable form by more or less formal rules, but in most cases such rules are not formal enough to be enforceable.

Ricky Clarkson

Posts: 63
Nickname: rclarkson
Registered: Jul, 2006

Re: Style is Substance

Posted: Jun 6, 2007 5:33 AM

Those here who think that XML would be a good solution - consider that Lisp, even used just as data (data is code is data..), is much more readable and easier to parse.


<class "Blah">
  <method "doSomething" return-type="void">
    <call "println">
      <get-static-field "out" from-class "System"/>
      <parameter "Doing something"/>
  </method>
</class>

or..


(class "Blah"
  (method "doSomething" return-type: "void"
    (call "println"
      (get-static-field "out" from-class: "System")
      (parameter "Doing something"))))

There's not a huge difference in the syntax, but there's enough that it is easier to read. The Lisp syntax is easier to write a parser for, and you can treat it as code in a number of programming languages (rather like you can with JSON).

The one problem I see with text-based syntax, including Lisp, is that it doesn't offer a way to have unnamed abstractions. Imagine you wrote two very similar methods. You could conceptually link their implementations so that when you changed one, the other changed, without having to define a third method, and performing the necessary mental acrobatics to work out what's going on.

I'm interested in seeing how new programmers deal with programs presented as mindmaps, which can have interlinked nodes. Because of its syntactic simplicity, Lisp is insanely easy to turn into mindmaps.

Maros Vranec

Posts: 1
Nickname: ramirez
Registered: Nov, 2007

Re: Style is Substance

Posted: Nov 27, 2007 4:15 AM

I agree with you almost completely, but I suggest less extreme solution. I have two reasons:

1. It is hard to convince everybody to use one style and not to move to another programming language.
2. It is hard to convince every programming language to listen to your suggestions.

The less powerful solution is that the style should be a concern of a revision control software.

You would define your favourite style for each project and repository would have its own style by agreement. After every check-out, the source code will be formatted to your style and before every other operation (e.g. diff) it will be reformatted back.

mais mais

Posts: 1
Nickname: mais
Registered: Jan, 2008

Re: Style is Substance

Posted: Jan 1, 2008 9:21 PM

Yes and no:
It is a personal thing and should _not_ be part of the compiler.

What you are going on about is merely a plugin/macro to your favorite editor that will take the _valid_ code and display it in whatever format you like.

Mark Wilden

Posts: 1
Nickname: mwilden
Registered: Feb, 2008

Re: Style is Substance

Posted: Feb 20, 2008 12:21 PM

I became a conscientious objector in the Formatting Wars after using Smalltalk. There, I got used to simply typing an entire (short) method body on one line, then pressing ^S to format the code and save it. Hell, let the computer do the formatting. It may not be exactly what I'd choose, but it's fast and easy.

///ark

John Calcote

Posts: 3
Nickname: jcalcote
Registered: Mar, 2005

Re: Style is Substance

Posted: Aug 3, 2012 11:58 AM

"In the end, this requires only that editors and IDEs used by coders will let the user type stuff and it will make it look right. This is basically just reformatting on the fly, which many editors already do. We don't need you to type zero, one or seventeen spaces between an <tt>if</tt> and its open paren, we just need the editor (assuming K&R C) to put exactly one space there. And getting even this right will be easier if there is only one style to worry about. It's one of those things that those reformatting or style adapting cycles can go to."

I know! Let's just push the reformatting one level deeper and let the compiler reformat the code right before it compiles it!

Lawson English

Posts: 1
Nickname: saijanai
Registered: Aug, 2012

Re: Style is Substance

Posted: Aug 10, 2012 8:39 AM

> I know! Let's just push the reformatting one level deeper
> and let the compiler reformat the code right before it
> compiles it!

In fact, that is what "save" does when you save a method in the Smalltalk IDE: it compiles it, and can be set to do formatting of the source before it compiles and saves both the source and the compiled bytecode.

Hans Scundal

Posts: 3
Nickname: irchans
Registered: Oct, 2012

Re: Style is Substance

Posted: Oct 28, 2012 11:38 AM

I, Irchans, know of a programming style whose impact on programmer productivity and/or program quality is >= 5% when compared to any major common style. That style is "see below" and its benefits are faster coding and better thinking about code.

Well, I don't really have any evidence so this is just opinion and I'm sure you have seen these ideas before, but I think this style improves productivity by over 5% for C++.

Rules:

1) At least 98% of your functions should be less than 40 lines of code. (I chose 40, but maybe 30 or 50 would be better.) I find it amazing how many programmers will write

for (i=0, i<iMax, i++)
{
// 300 lines of code
}

2) Put assertion at the front of most functions if your language does not support restricted range subtypes (as in Ada). If it supports subtypes, use them.

3) Use Lint.

4) Any function of over 20 lines of code deserves a comment.

5) If your variable is known to have specific physical units (like cm, feet, miles, watts, square meters), put the units in the variable name.

6) Use light Hungarian Notation (http://en.wikipedia.org/wiki/Hungarian_notation). (i.e. prefix integer types with an i, strings with an s, ...) I suggest that you don't use more complicated Hungarian Notation.

7) Program in a strongly typed language (like Haskell or Ada) if you can.

Cheers,
irchans

Hans Scundal

Posts: 3
Nickname: irchans
Registered: Oct, 2012

Re: Style is Substance

Posted: Oct 28, 2012 11:42 AM

Oh, I forgot, one more suggestion. Line things up when you can. Make it pretty. For example,


   b = (i <  13) && bFlag7  && (i11 >= 17)
       (i >   5) && bFlat11 && (i11 <   4);

Hans Scundal

Posts: 3
Nickname: irchans
Registered: Oct, 2012

Re: Style is Substance

Posted: Oct 28, 2012 11:43 AM

Well, the white space in my previous comment did not show up, so ignore the example.

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

Previous Topic

Next Topic