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

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

Berend de Boer wrote:
> 
> With Emacs you can tabify sources when you load them and untabify when
> saved.

What do you mean by "tabify"? Do you mean replace spaces by tabs?

> If people cut and paste code from other editors, html browsers,
> whatever you end up with a mix.

Copy/paste is bad practice anyway, you should inherit!
Well OK, it's hard to inherit from an HTML document ;-)

> At least I couldn't find any of your code
> that uses spaces AND tabs for indenting :-)

I'm very consistent when I write code, be it for indentation
or other things. Well, at least I try to be, I'm just a
human being who can make mistakes as anybody else...

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

3. you cannot set indentations to the size you want.

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

Are you saying that it gives better formatting results in
example classes but not in library classes? Hmmm...

> Raising exceptions is a core feature of eposix:

Yes, that's what I read in your doc, and to say the least that's
not what I prefer the most in the design 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 personally prefer the style of trying to create a directory
and then check to see whether the creation succeeded or not.
That way the code to handle the problem is near the source of
the problem, whereas with exceptions it is generally far away,
because exceptions have not really been designed in Eiffel
to be part of the flow of control.

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

Yes.

>  There should be exceptions when the contract cannot be
> fullfilled, so it should be in the contract.

If the contract (i.e. postcondition) is not fulfilled, then there
is a problem in the implementation of the routine, and it should
be fixed or the contract should be reworked. That's my point of
view at least. I don't think that it is up to the client to handle
problems to fulfill the psotcondition by the implementation of the
suppliers.

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