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

[Berend de B. <be...@po...>]

Eric Bezault <er...@go...> writes:

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

With Emacs you can tabify sources when you load them and untabify when
saved. If you can do this with vim you can have tabs the way you want.

So it all boils down to the choice of the proper editor :-))


> > and sources with tabs looks really ugly on my system for example.
> 
> What do you mean by ugly?

If people cut and paste code from other editors, html browsers,
whatever you end up with a mix. And that looks ugly. And emacs is
customizable so you can press tab and have spaces inserted (what many
people use), you can set this with vim too, but few people seem to
customize vim.


> > 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).

I was wrong here, sorry. At least I couldn't find any of your code
that uses spaces AND tabs for indenting :-)


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

With only spaces:
1. your layout is never destroyed
2. looks the same on any viewer, even those that do not handle tabs
properly as the original vi.


> > > (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.

You can make this optional. eposix uses the OOSC2 almost
excusively. For examples (better formatting results) I use your
approach.


> > 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.

Raising exceptions is a core feature of eposix: if you ask to create a
directory, it is created or you get an exception. Every failure gives
you can exception so you don't continue in case of failure.

I don't think I use exceptions where it is not clear from the ensure
clause (which I admit is not always there )-: ).

Can you agree that when the ensure clause exists, the comment is
superfluous? There should be exceptions when the contract cannot be
fullfilled, so it should be in the contract.

If it is not in the contract, perhaps you shouldn't generate
exceptions (so a comment is an indication that something is wrong).

Groetjes,

Berend. (-: