Hi Jan, You came to the same conclusion as me to which rules do not apply to Symfony from the ones found in the sfAuditPlugin. I did remove the exact same ones.
1. Concat operator must not be surrounded by spaces 2. The "no space after object operator"-rule has to be removed to allow fluent APIs I did not do anything about the control structures in the templates and it all validates fine. As I said the plugin is very specific to their needs but just it happens that they have the same needs as we do. That is they validate for no spaces at the end of lines, they check for SVN properties (line endings and image mime types), they check for space found before semicolon. The SVN checks are very important, as other people can testify, because when working with other developers, you have different setup of their dev machines and also different OS in many cases. The same with the spaces in the end of the line. How many times you get a file marked as modified and the lines are absolutely the same apart from the line ending or some spaces in the end which cannot be seen with the editor? So I was happy that other people have come to the same conclusions and I would recommend for Symfony to audit, if not enforce, all these practices. Of course the SVN specifics should be left as optional but aren't they valid for any VCS? I would be happy to work on the plugin to make it suitable for general use but that will not happen before next year so if somebody else wants to take that first, I will be able to test and comment. Kiril On Mon, Dec 15, 2008 at 12:02 PM, Jan Markmann <[email protected]> wrote: > > > > On 13 Dez., 16:36, "Kiril Angov" <[email protected]> wrote: >> us. I just removed two coding standards enforcements which are not >> really in the Symfony standard and I have been fixing several places >> where we did not follow the right way of writing. > > @ Kiril Angov: Can you post which rules you removed? > I think we dont need a wokring plugin yet but a working coding > standard. > If that standard definition enforces the correct rules, nothing else > and nothing less, then anybody can use it to run PHP_CodeSniffer > against any code. > Incorporating this into a plugin would be another topic since it is > not the only possible usage of this coding standard. > >> On Sat, Dec 13, 2008 at 1:50 PM, halfer >> >> <[email protected]> wrote: >> >> > Should anyone be able to adjust this plugin so it doesn't throw up >> > issues against the core (or, indeed, highlights genuine standard >> > violations in the core) I'd be interested in reading about their >> > results. I see that coding standards in this product are customisable >> > too - great!: >> >> >http://pear.php.net/manual/en/package.php.php-codesniffer.coding-stan... > @halfer: If you dont want to run it against the core take a look at > PHP_CodeSniffers command line options where you can specify which > files and folders to include and/or exclude. > > @community/symfony core team: > After Kiril posted back his changes to the standard could anyone who > is a little more used to sticking with symfony coding standards please > run it again symfonys core or a test project and tell what rules need > to be removed or tweaked? > I am having a feeling the coding standard definition only needs a > little tweaking on a handful of rules or less and that it would then > fully comply to symfonys coding standards. > The standards defined in > http://trac.symfony-project.org/wiki/HowToContributeToSymfony > do not state whether some rules are applicable or not. > Errors I am still uncertain of are: > - End of line character is invalid; expected "\n" but found "\r\n" > - Whitespace found at end of line > - String "..." does not require double quotes; use single quotes > instead > - Expected "if (...)\n"; found "if(...)\n" > - Concat operator must not be surrounded by spaces. Found "...er\n". > \n ..."; expected "...er\n". ..." > The first 3 errors are the most frequent thrown ones. If we could > clarify these errors we might already have a very good standard > definition since there are few other errors and warnings and most of > them look very applicable to symfony coding standards. > Until now I found 2 rules that have to be tweaked (hoping and waiting > for Kirkil's feedback what else he removed): > - The "no space after object operator"-rule has to be removed to allow > fluent APIs > - The control structures rule has to be tweaked to allow the style > used in symfony templates > > I hope we can clarify the applicability of the rules soon, since > tweaking the coding standard definition does not seem to be that hard, > but clarification of rules applicability is a precondition to that. > Any feedback and/or comment about the rules applicability is very > welcome. > If you need an output from PHP_CodeSniffer run against symfony 1.2 > core to get an idea of what is validated yet don't hesitate to contact > me, so I can send you a log. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
