Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » If you want to avoid annoying CS commits »

If you want to avoid annoying CS commits

php.internals

Sterling Hughes

23 years ago
Howdy, Due to recent discussions, I have an idea for avoiding the whole mess of annoying coding standards commits that Jani and Derick constantly make. Follow the coding standards! Geeze Luise, its not that hard, and the coding standards are there for a (good) reason. If you object to some of the standards, discuss that, but the source code should follow a unified style: we have agreed to this a long time ago. Don't yell at Jani and Derick when you screw up; and if you really can't stand it, move your extension to PECL. -Sterling
-- "The computer programmer is a creator of universes for which he alone is responsible. Universes of virtually unlimited complexity can be created in the form of computer programs." - Joseph Weizenbaum

Lukas Smith

23 years ago
> From: Sterling Hughes [mailto:sterling@bumblebury.com] > Sent: Friday, April 04, 2003 6:09 PM
> Geeze Luise, its not that hard, and the coding standards are there for
a
> (good) reason. If you object to some of the standards, discuss that, > but the source code should follow a unified style: we have agreed to > this a long time ago. Don't yell at Jani and Derick when you screw
up;
> and if you really can't stand it, move your extension to PECL.
Even in PECL you have to follow the php coding standards. Regards, Lukas

Sterling Hughes

23 years ago
On Fri, 2003-04-04 at 11:45, Lukas Smith wrote:
> > From: Sterling Hughes [mailto:sterling@bumblebury.com] > > Sent: Friday, April 04, 2003 6:09 PM > > > Geeze Luise, its not that hard, and the coding standards are there for > a > > (good) reason. If you object to some of the standards, discuss that, > > but the source code should follow a unified style: we have agreed to > > this a long time ago. Don't yell at Jani and Derick when you screw > up; > > and if you really can't stand it, move your extension to PECL. > > Even in PECL you have to follow the php coding standards. >
No, in PEAR. In PECL your code can look however it likes, at least that's my understanding. :) You *own* the project, PECL justs hosts it, its not a part of anything greater. I believe that's how it was designed, and that's certainly how it should be. -Sterling
> Regards, > Lukas
-- "I can't give you a brain, so I'll give you a diploma" - The Great Oz, The Wizard of Oz

Martin Jansen

23 years ago
On Fri, 2003-04-04 at 18:26, Sterling Hughes wrote:
> No, in PEAR. In PECL your code can look however it likes, at least > that's my understanding.
The manual states it differently: "In PECL all code has to follow the PHP coding standards." (http://pear.php.net/manual/en/developers.meaning.php) - Martin

Sterling Hughes

23 years ago
On Fri, 2003-04-04 at 12:26, Martin Jansen wrote:
> On Fri, 2003-04-04 at 18:26, Sterling Hughes wrote: > > No, in PEAR. In PECL your code can look however it likes, at least > > that's my understanding. > > The manual states it differently: > > "In PECL all code has to follow the PHP coding standards." > (http://pear.php.net/manual/en/developers.meaning.php) >
Then the manual is wrong. PECL extensions are independent entities with no interdependencies (fully encapsulated). The api's they export should follow naming conventions - sure. But following coding standards misses the point of pecl itself (to foster independent extension development.) -Sterling5
> - Martin
-- "First they ignore you, then they laugh at you, then they fight you, then you win." - Gandhi

Martin Jansen

23 years ago
On Fri, 2003-04-04 at 19:15, Sterling Hughes wrote:
> On Fri, 2003-04-04 at 12:26, Martin Jansen wrote: > > "In PECL all code has to follow the PHP coding standards." > > (http://pear.php.net/manual/en/developers.meaning.php) > > > > Then the manual is wrong.
Oh, come on: You should have come up with that at the time that Stig hammered out PECL.
> PECL extensions are independent entities with > no interdependencies (fully encapsulated). The api's they export should > follow naming conventions - sure. But following coding standards misses > the point of pecl itself (to foster independent extension development.)
At least PECL is a part of PEAR and thus should be at least somewhat consistent. Without coding standards this will surely not happen. - Martin

Sterling Hughes

23 years ago
On Fri, 2003-04-04 at 12:42, Martin Jansen wrote:
> On Fri, 2003-04-04 at 19:15, Sterling Hughes wrote: > > On Fri, 2003-04-04 at 12:26, Martin Jansen wrote: > > > "In PECL all code has to follow the PHP coding standards." > > > (http://pear.php.net/manual/en/developers.meaning.php) > > > > > > > Then the manual is wrong. > > Oh, come on: You should have come up with that at the time that Stig > hammered out PECL.
Speak Now or forever hold your peace? Got news for you, 3/4s of the stuff in pecl doesn't follow the coding standards. I just looked at the first 5 modules by ls, none of them were coding standards compliant.
> > > PECL extensions are independent entities with > > no interdependencies (fully encapsulated). The api's they export should > > follow naming conventions - sure. But following coding standards misses > > the point of pecl itself (to foster independent extension development.) > > At least PECL is a part of PEAR and thus should be at least somewhat > consistent. Without coding standards this will surely not happen.
What's the point, really? PECL modules are not group maintained (like PEAR modules). If I woke up one day and saw someone committed to my pecl module without my consent (or without contacting me first), I would revert it just for good measure.. When you have something in PECL, its *your* project, its not everyone's business (like in PHP). Also developing PHP extensions is much different than developing PHP. In PHP extensions the code itself is much more encapsulated, in PECL individual package development is encapsulated. As long as the code follows the php naming conventions (for exported functions), it can interact nicely with the other packages. Forcing developers to use one coding style in their individual projects will needlessly limit contributions to PECL, and have no external benefit. -Sterling
> - Martin
-- "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup

Rasmus Lerdorf

23 years ago
> Also developing PHP extensions is much different than developing PHP. > In PHP extensions the code itself is much more encapsulated, in PECL > individual package development is encapsulated. As long as the code > follows the php naming conventions (for exported functions), it can > interact nicely with the other packages. Forcing developers to use one > coding style in their individual projects will needlessly limit > contributions to PECL, and have no external benefit.
Also, don't forget that a PHP extension is often a small part of a much larger project that may also have Perl and Python support, for example. It would certainly be beneficial if the PHP part of such a project could be part of PECL and forcing the authors to adhere to our highly arbitrary coding standards is not a good idea in such a case. I think people are getting way too worked up over coding standards. They should be treated as a guideline not as an absolute, even in the core PHP code. Small deviations from the standard makes absolutely no difference to the readability of the code. if(blah==SUCCESS) vs if(blah == SUCCESS) Nobody is going to get get that confused, but yes, technically this is a CS violation. And it appears at least 56 times in the current 4.3 code: 10:00am thinkpad:~/php43> grep "==SUCCESS" */*.c */*/*.c | wc -l 56 And Jani, if you go through and clutter up CVS with fixes for each of those I will whack you with a smelly trout. -Rasmus

Martin Jansen

23 years ago
On Fri, 2003-04-04 at 19:35, Sterling Hughes wrote:
> On Fri, 2003-04-04 at 12:42, Martin Jansen wrote: > > On Fri, 2003-04-04 at 19:15, Sterling Hughes wrote: > > > On Fri, 2003-04-04 at 12:26, Martin Jansen wrote: > > > > "In PECL all code has to follow the PHP coding standards." > > > > (http://pear.php.net/manual/en/developers.meaning.php) > > > > > > > > > > Then the manual is wrong. > > > > Oh, come on: You should have come up with that at the time that Stig > > hammered out PECL. > > Speak Now or forever hold your peace?
That's now what I meant to say and you know that. What I intended to say was that it's not very productive to question something _after_ it has been hammered out, if you had the chance to actively influence it's direction _before_ there was a decision.
> Got news for you, 3/4s of the stuff in pecl doesn't follow the coding > standards. I just looked at the first 5 modules by ls, none of them > were coding standards compliant.
In this case the people, who wrote that code, haven't read the passage from the manual, which I've quoted. Sad but true.
> What's the point, really? PECL modules are not group maintained (like > PEAR modules). If I woke up one day and saw someone committed to my > pecl module without my consent (or without contacting me first), I would > revert it just for good measure.. When you have something in PECL, its > *your* project, its not everyone's business (like in PHP).
Hmm, I can see the danger of PECL becoming a "garbage dump" in this sentences. But may be I'm wrong.
> Also developing PHP extensions is much different than developing PHP. > In PHP extensions the code itself is much more encapsulated, in PECL > individual package development is encapsulated. As long as the code > follows the php naming conventions (for exported functions), it can > interact nicely with the other packages.
Again: This point of view seems to clash with the vision that Stig and some others over at pear-dev had about PECL. Anyways, I don't really care about PECL much at the moment and thus won't invest to much energy in this discussion ;-). - Martin

Philip Olson

23 years ago
> Again: This point of view seems to clash with the vision that Stig and > some others over at pear-dev had about PECL. Anyways, I don't really > care about PECL much at the moment and thus won't invest to much energy > in this discussion ;-).
The vision is different for everyone it seems. Last I heard, just about every extension will be moved into PECL with most still bundled but regardless they all will be in PECL. Is this the end of coding standards in php extensions? Nice loop hole ;) Regards, Philip

Zeev Suraski

23 years ago
At 19:49 05/04/2003, Philip Olson wrote:
> > Again: This point of view seems to clash with the vision that Stig and > > some others over at pear-dev had about PECL. Anyways, I don't really > > care about PECL much at the moment and thus won't invest to much energy > > in this discussion ;-). > >The vision is different for everyone it seems. Last I heard, >just about every extension will be moved into PECL with most >still bundled but regardless they all will be in PECL. Is >this the end of coding standards in php extensions? Nice >loop hole ;)
My thoughts exactly. I think PECL code should follow the standards just as the rest of PHP. If you write a library that's also reused in other projects, by all means, use whatever coding style you want, but put the common parts out of PECL. Zeev

Sascha Schumann

23 years ago
Sterling, you are missing some important points here.
> Geeze Luise, its not that hard, and the coding standards are there for a > (good) reason. If you object to some of the standards, discuss that,
If you look at my code, 99% of it follows the coding styles, because I've adopted the PHP style as my personal one. The commit I recently backed out related mostly to Zeev's "terse" style. While I'm not particular fond of it, there is also no reason why it absolutely has to be realigned. I barked at Derick for trying to police me with his docref pet stuff. I just noticed that someone has committed that to CODING_STANDARDS, although there has never been a consensus regarding its introduction. As such, I consider it to be void. - Sascha

Sterling Hughes

23 years ago
On Fri, 2003-04-04 at 11:54, Sascha Schumann wrote:
> Sterling, you are missing some important points here. > > > Geeze Luise, its not that hard, and the coding standards are there for a > > (good) reason. If you object to some of the standards, discuss that, > > If you look at my code, 99% of it follows the coding styles, > because I've adopted the PHP style as my personal one. > > The commit I recently backed out related mostly to Zeev's > "terse" style. While I'm not particular fond of it, there is > also no reason why it absolutely has to be realigned. > > I barked at Derick for trying to police me with his docref > pet stuff. I just noticed that someone has committed that to > CODING_STANDARDS, although there has never been a consensus > regarding its introduction. As such, I consider it to be > void. >
Ahh, well, you should follow the coding standards regardless, or rather change them. I've just removed docref and assert bogusness from the files, so, in that case, you are no longer in violation. (you should throw a party. ;-) What I was objecting to was less contraversial, long term coding standards, for example: if (foo) bar = 1; instead of : if (foo) { bar = 1; } Its really quite simple to follow, and if you want to avoid annoying CS commits, just follow the standards. -Sterling
-- "The three most dangerous things in the world are a programmer with a soldering iron, a hardware type with a program patch and a user with an idea." - Unknown

Moriyoshi Koizumi

23 years ago
Sterling Hughes <sterling@bumblebury.com> wrote:
> > Ahh, well, you should follow the coding standards regardless, or rather > change them. I've just removed docref and assert bogusness from the > files, so, in that case, you are no longer in violation. (you should > throw a party. ;-)
Hmm, I partly agree with you about the docref cluttering, but what's wrong with assert? Moriyoshi

Joseph Tate

23 years ago
How about documenting an astyle (insert stylizing app of choice here) line in CODING_STANDARDS that people can run on their code to make it conform to said standards. Then people can just run $astyle on their file before they commit it. Joseph

Tom Sommer

23 years ago
On Fri, 4 Apr 2003 12:11:16 -0500, Joseph Tate wrote:
> How about documenting an astyle (insert stylizing app of choice here) line > in CODING_STANDARDS that people can run on their code to make it conform to > said standards.
What astyle would you suggest?
-- Tom Sommer, Denmark www.tsn.dk - www.dreamcoder.dk

Joseph Tate

23 years ago
Something like astyle --style=kr --pad=all (reformat in Kernighan and Ritchie style and pad all operators and parens with spaces) might be sufficient. It might not catch if(foo)bar, but it'll go a long way to reducing the number of ws and superficial style fixes that need to be done. Joseph

Derick Rethans

23 years ago
On Fri, 4 Apr 2003, Sascha Schumann wrote:
> I barked at Derick for trying to police me with his docref > pet stuff.
1. It's not my stuff 2. I'm not particulairy fond of it either, but that doesn't mean I don't use it in my code for the PHP project.You may object or not, but if it's generally adopted you should too. It's not playing police here, it's just common sense between the developers of a big project like PHP. Personal opinions are not always the ones that should be followed. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Sascha Schumann

23 years ago
Derick, your attempts at setting rules are misguided. - Sascha

Derick Rethans

23 years ago
On Fri, 4 Apr 2003, Sascha Schumann wrote:
> Derick, your attempts at setting rules are misguided.
I'm not setting any rules, I'm just trying to push ways of effective collaboration due to the adoption of the same standards for everbody. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Sascha Schumann

23 years ago
> I'm not setting any rules, I'm just trying to push ways of effective > collaboration due to the adoption of the same standards for everbody.
You are in no position to push anything. Try 'encouraging' or 'convincing' the next time. - Sascha

Derick Rethans

23 years ago
On Fri, 4 Apr 2003, Sascha Schumann wrote:
> > I'm not setting any rules, I'm just trying to push ways of effective > > collaboration due to the adoption of the same standards for everbody. > > You are in no position to push anything. > > Try 'encouraging' or 'convincing' the next time.
The difference between 'pushing' and 'encouraging' is tought in management school. The semantical difference is NULL. Derick
-- "my other box is your windows PC" ------------------------------------------------------------------------- Derick Rethans http://derickrethans.nl/ PHP Magazine - PHP Magazine for Professionals http://php-mag.net/ -------------------------------------------------------------------------

Sascha Schumann

23 years ago
> The difference between 'pushing' and 'encouraging' is tought in > management school. The semantical difference is NULL.
Derick, you need to realize that you lack authority. Someone without authority cannot push anything what so ever. Or to put it differently: A bully pushes. A peer encourages. - Sascha