Re: [gobo-eiffel-develop] Developer Guidelines (first draft)

[Eric B. <er...@go...>]

Berend de Boer wrote:
> 
> What about the create construct?

It is not supported by Visual Eiffel yet.

> Forbid tabs. Everybody uses a different tab width 

Yes, and that exactly why we should use tabs. With spaces
we cannot set the size of indentations to personal preferences.

> and sources with tabs looks really ugly on my system for example.

What do you mean by ugly?

> Your code with tabs looks ugly on any editor with tabs set to
> something different than 8 spaces ro whatever you have.

I'm sorry but I don't agree. I set the tab width to different
sizes and the code is still indented properly and still looks
fine to me. (BTW, I usually use a size of 4).

> Tabs are bad.

This is your opinion. On the other hand I think that spaces
are bad.

> > (Borrow the guidelines from OOSC2 section 26.5 page 891.
> > Note that contrary to the guidelines in OOSC2, the
> > recommended layout for Gobo Eiffel classes in to put
> > the class name on the same line as the 'class' keyword
> > -- see class BAR above.)
> 
> Why differ from OOSC2? I see absolutely no need for this. Just follow
> OOSC2 and you're almost guaranteed that acceptible libraries for Gobo
> are formatted correctly.

I differ from OOSC2 because all the Eiffel code that I wrote
or saw in the projects I work on during the past 10 years or
more (even when I was at ISE) put the class name on the same
line as the 'class' keyword. That's all.

> That's almost any routine in eposix. Hard to specify I think. The
> ensure clause should be enough to see that an exception
> follows. Putting it again in the header comment seems superfluous to
> me.

I think that it is bad pratice to raise exceptions in Eiffel.
But at least we should know when such exceptions may occur.
I don't think this is superfluous.

-- 
Eric Bezault
mailto:er...@go...
http://www.gobosoft.com