Re: [limesurvey-developers] RE : About coding rules (revised)

[Thibault Le M. <Thi...@su...>]

>=20
> sMyString
> asMyStrings
> asMyFunctionReturnsStringArray()
>=20
> You are right.
> Thanks Thibault!

You're welcome.

> http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocument
> or/tutorial_p
> > hpDocumentor.quickstart.pkg.html#coding) or similar
> > things ?
> >=20
> Good point.. I never use that facilities... Ideas?

Well, I think that for limeS 2.0 a facility _such_as_ phpDocumentor is a
MUST, but I don't know which documentor system to use because I think =
there
are others... (doxygen beeing one other famous see
http://www.faqs.org/docs/Linux-HOWTO/PHP-HOWTO.html#s18).

> > I disagree... We MUST decide whether to use Tabs OR
> > Spaces otherwise the
> > code becomes very ugly from on editor to another.

My 'disagree' word meant I think we must decide a mandatory rule: wheter =
we
use TAB or SPACES is an interresting question but not as crucial as to =
avoid
using both at the same time ;-)

So I should have written "We MUST decide whether to use Tabs XOR Spaces"

> > I prefer tabs because it's easy then to let anyone
> > choose the tab length to
> > suit its editor width (that's why I often changes
> > space indents to tabs in
> > the code when possible). However if we decide to use
> > spaces, we MUST
> > explicitely impose the number of spaces used for a
> > single ident.

=3D=3D> That was just a little personnal opinion ;-)
 What do other dev think ?

> Yes, I understand.. But, let me show you that:
> if ()
> {
> =B7=B7=B7code
> }
> for ()
> {
> =B7=B7=B7=B7code
> }
> foreach ()
> {
> =B7=B7=B7=B7=B7=B7=B7=B7code
> }
> If you want to indent the code block with the
> brackets, it is hard to achieve it with tabs.

Really? Why?
I must admit I'm only using Vim to code and am still identing with vim
commands so I may not understand this need.
Anyway, I'm not against 'Spaces' ident if it becomes 'Spaces only' =
ident.

> I think
> that any text editor has autoindent... Perhaps a
> middle point can be: using tabs (with an arranged
> lenght) and complemented with spaces...

Humm... I _really_ prefer avoiding mixed ident format.

 > >   BAD: if (condition) {do true} else {do false}
> > >   BAD: if (condition) {do true}=20
> > >        else {do false}
> > >   GOOD: if (condition)
> > >         {
> > >            do true
> > >         } else
> > >         {
> > >            do false
> > >         }
> >=20
> > I agree but sometimes the code may become 'over
> > idented' and using tricks
> > like this may make the code more readable in some
> > specific cases...
> Thibault, let me save this point: I=B4m trying to
> "stablish a standard". I=B4m not trying to do a
> "compulsive" rule... Just to "suggest" a way to writte
> code "undersandable" to every one...=20

That how I see it, i had only like to get others point of view on this:
should we ban the 'one line -if-else- form' or should we accept in very
specific cases (simple action, high ident level) this format ?

If we decide to accept this, we should write it on the Coding rules =
page.
But of course I can live without it: to be honest I'm not a big fan of =
this
;-)

> But if XHTML standard recomends it, use the /> where
> is needed, even it is optional.

Sure.

> > > - If using an auxiliar variable makes clear the
> > code or
> > > process, just do it.
> >=20
> > ??? Can you be more specific I don't catch this
> Yes, of course. I mean if you are coding a very
> complex expression, calling to functions with
> parameters that are other functions:
> iAResult=3D fa(fb(p1,p2),fc(fd(p3),p4),p5)
> It will be more readdable:
> iAuxB =3D fb(p1,p2)
> iAuxD =3D fd(p3)
> iAuxC =3D fc(iAuxD,p4)
> iAResult =3D fa(iAuxB, iAuxC, p5)
> or some other kind of examples that I can remmember
> right now...

Very clear, I agree.
The example is worth adding to the wiki too I think.

> Thanks a lot for your collaboration.

Thanks to you, the coding rules was something really missing to limeS.

Thibault