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

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

Berend de Boer wrote:
> 
> Eric Bezault <er...@go...> writes:
> 
> >   The comb structure uses indentation, achieved through tab
> >   characters (*not* spaces, which are messy, error-prone, and
> >   not reader-parameterizable).
> 
> they're not parameterizable with every reader, so they look strange in
> certain cases. And perhaps they are in ISE's IDE, but haven't detected
> that option...
> 
> > From what I can see, it seems that the size of tabs used in
> > examples in OOSC2 is 4.
> 
> Hmm, I think it's 6 or perhaps just some xx em, not really clear.
> 
> > Then I don't see where the problem is. You can convert
> > tabs to 3 spaces when you load the Eiffel class into Emacs,
> > and convert them back to tabs when you save the file.
> 
> Then I don't see where the problem is. You can convert 3 spaces to
> tabs when you load the Eiffel class into vim, and convert them back to
> tabs when you save the file :-))

I don't understand: on one hand you say that we should follow
OOSC2 guidelines and not reinvent the wheel, and on the other
hand you reject it when it does not fit your liking.

> The point is that sometimes you have tabs in the file, sometimes
> not. Not all editors handle tabs great, so just do away with them.
> 
> I agree that your source code works fine with tabs, but most others
> don't. Take the SmallEiffel code,

Written using Emacs...

> take EXML, 

Written using Emacs...

> take whatever source file you might lay your hands upon.

I don't know about this one ;-)

I know, it is not an editor problem, unless proven otherwise ;-)

> But whatever we decide, what are our options to guarantee it is done
> consistently?

That's what guidelines are for, and that's why I explicitly
put this rule in the first draft of the guidelines. I was
hoping that people would follow the guidelines without me
having to play the cop. What are the options to guarantee that
people will use spaces consistently if we decide to go with
spaces? What are the options to guarantee that all the other
rules specified in the guidelines are followed consistently?
To be honest I would prefer people to care by themselves
about writing consistent code (that's why I started to write
some guidelines) rather than to waste my time writing tools
and scripts to check that nobody violates the rules. But if you
think that such tools and scripts should be written because
we cannot trust Eiffel programmers, well... sadly let's do it.

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