Does someone sees a problem if an optional app (not the core) uses its
own coding convention ?
We (the claroline team) are thinking to follow this convention for
naming the classes :
http://groups.google.com/group/php-standards/web/psr-0-final-proposal
except for the ones loaded by the framew
Hi Philippe,
Yes, I see this as being a big problem.
The conventions apply to the entire codebase (except for plugins
obviously). While I realize only too well that everyone has their own
preferences and while other projects might have chosen a different
approach in the past, the current rule
Hi Yannick,
Ever since the initial translation tool was written, considerable
improvements were added to Chamilo 2 to tackle exactly this kind of
problem. There are no doubt still quite a few variables that don't
adhere to these "rules", but the infrastructure is definitely there to
allow it.
Hi Philippe,
Could you please provide a bit of information about the why/how/what of
the inclusion of TWIG in the global plugin folder?
Thanks in advance,
Hans
On 05/05/2011 15:14, Chamilo 2 AT Bitbucket wrote:
Repository: chamilo-dev
Revision: 2128
Node: 111fe0291cb4
Link:https://bitbucket.
>
> Does someone sees a problem if an optional app (not the core) uses its
> own coding convention ?
>
> We (the claroline team) are thinking to follow this convention for
> naming the classes :
> http://groups.google.com/group/php-standards/web/psr-0-final-proposal
> except for the ones loa
Hi Hans (& everybody)
This is part of the FrontController / Request / Response / etc refactoring.
Unofrtunately, I can't share the work I've already done without breaking
at least some stuff, even if I did my best to design the code I wrote to
not break anything.
Therefore I will rework the
Systho,
It is really important that you wait with this kind of stuff until we
have merged stable to dev and dev to stable (end of may). All production
system need to work on the current dev code .. and spending time fixing
bugs related to new refactoring operations is not what we want right no
I was just asking , we are starting from scratch so we are evaluating
lots of decisions which have been made previously and we do not
understand withtout hints. It's not that difficult to go for underscore
notation but if it's not completely forced we would have chose to keep
the same notation
I know , this is why I don't pushed any of the classes I write but only
the plugin.
I wouldn't have thought it would be such a problem, I'll remove it
Systho
Le 5/05/2011 15:52, Stefaan Vanbillemont a écrit :
Systho,
It is really important that you wait with this kind of stuff until we
have
Hi Philippe,
While I realize you're very enthusiastic about this I would really
advise you to go ahead slowly (well slower anyway) with this. We still
have a very long way to go untill the entire FrontController-thingamabob
gets implemented in Chamilo 2.
It's no real problem that you added i
Hi Philippe,
The CamelCase-convention dates back to just before I joined the project,
so I can't help you as to the why of it. (so I doubt anyone can tell you
now) I've never had a problem with it and saw no reason to change it
back then. Most of the other libraries weren't as big or well-know
Well in general in 1.8 we apply the naming convention strictly to files,
functions and variables, but not to classes names.
It's a bit weird, I know, but I'm flexible about it (in 1.8, that is) as
long as it's not into the core or there's no dependency on that, and
mostly because in the beginning
I can only but concur to what has already been said.
The other thing is that it would be nice to have a coding convention
that can be applied by the major tools - netbeans, eclipse, etc.
So that we don't have to bother too much.
I must confess that I use pretty printing a lot and was unable to
Hi
For the visibility and readability of the code we really try to avoid
such type of code. This is one of the points of the coding conventions
that is very important to me. When I train new people I spent a lot of
time explaining to them that we should try to avoid such constructions
in orde
14 matches
Mail list logo
