Welcome Guest, Not a member yet? Register   Sign In
A question about the future coding style guide
#11

I don't care coding styles much. So I changed my style to PSR-2.

The book "Modern PHP" says:
Quote:A standard code style also lowers the barrier for new project contributors, who
can spend more time squashing bugs and less time learning an unfamiliar style.

I don't say PSR-2 is standard, but is de facto standard.
All modern PHP frameworks now adopt PSR-2.
Reply
#12

(This post was last modified: 01-04-2016, 12:11 AM by sv3tli0.)

CI standard is about the framework.
Anyone is free to use any other standard for his own app if it works with CI..

I think that both CI and some CI App should use just 1 standard for easier contribution but it doesn't has to be the same for both.
Best VPS Hosting : Digital Ocean
Reply
#13

I know it. I use PSR-2 for my applications.
Because if I use it, I can use some tools which support it.
And many people are familiar with it. In contrast, only CI users know CodeIgiter's sytle.

I'm talking and asking about CodeIgniter's coding style.
I don't see the benefit to use the custom coding style.

If you guys support to use the current custom style, would you please tell me the benefits?
My question is just why don't you use the de facto standard?
Reply
#14

There are no benefits to using PSR-2 over another well-thought styleguide, nor is there any meaning in tools "supporting" it - that's just a fallacy.

Styleguides help in having readable, consistent, well-structured code and nothing else. It's a document telling you where to put brackets and how to use whitespace, not something that has functional benefits; nothing will collapse if you don't follow a particular one.
Reply
#15

http://cs.sensiolabs.org
https://github.com/bobsta63/netbeans-psr-formatting
Probably there are more developments like these.

Automation on code styling would be nice, then more time and commits would be spent on creative subjects.
Reply
#16

> nor is there any meaning in tools "supporting" it - that's just a fallacy.

Sorry, my English is just broken.

I meant tools like:
* PHP Coding Standards Fixer http://cs.sensiolabs.org
* PhpStorm https://www.jetbrains.com/phpstorm/
* Nitpick CI https://nitpick-ci.com/

What can I say them?
Reply
#17

(01-04-2016, 10:44 PM)kenjis Wrote: ...

What can I say them?

You could always suggest that there are tools that support any number of coding style conventions, including ours. One example is the  Z-Ray tool for Zend Server (see image attached).


Not everyone agrees with the PHP-FIG conventions (or at least all of them), nor does everyone believe that the sun rises and sets with the group.

Following a coding style convention does not add functionality to your code - it makes it easier to "read" in a specific context. Our conventions are intended to address consistency in the framework codebase.

There is nothing to prevent you from following PSR2 or PSR37 inside your application, if that makes it easier for you to work with Smile

Attached Files Thumbnail(s)
   
James Parry
Project Lead
Reply
#18

I hate PSR-2. In a perfect world, everyone would conform their coding style to my liking Smile
Reply
#19

(01-04-2016, 04:30 AM)ivantcholakov Wrote: http://cs.sensiolabs.org
https://github.com/bobsta63/netbeans-psr-formatting
Probably there are more developments like these.

Automation on code styling would be nice, then more time and commits would be spent on creative subjects.

(01-04-2016, 10:44 PM)kenjis Wrote: > nor is there any meaning in tools "supporting" it - that's just a fallacy.

Sorry, my English is just broken.

I meant tools like:
* PHP Coding Standards Fixer http://cs.sensiolabs.org
* PhpStorm https://www.jetbrains.com/phpstorm/
* Nitpick CI https://nitpick-ci.com/

What can I say them?

Nah, your English is OK. I assumed by "tools" you meant other frameworks and libraries. But IDE functionalities as arguments in this context is another common fallacy and sadly, I've even seen it in PHP RFCs.

That's like rejecting a new feature because an IDE doesn't support auto-completion for it - of course it doesn't support it if it doesn't exist yet. Such tools are written to help you and are driven by frameworks', libraries' and language's features, not the other way around.

These tools had support for other "standards" before PSR-2 existed, somebody wrote the patches or plugins for it afterwards; the same will happen for every popular styleguide.
Reply
#20

(01-04-2016, 10:44 PM)kenjis Wrote: > nor is there any meaning in tools "supporting" it - that's just a fallacy.

Sorry, my English is just broken.

I meant tools like:
* PHP Coding Standards Fixer http://cs.sensiolabs.org
* PhpStorm https://www.jetbrains.com/phpstorm/
* Nitpick CI https://nitpick-ci.com/

What can I say them?

To be fair - I believe all of these tools allow you to specify your own ruleset for it to check against, just like they provide one for PSR1 & 2.

One thing that I know for sure is that when the PSR's were originally announced the PHP world became a heap of arguing over spaces vs tabs which, really doesn't matter in the long run. That argument has died down, mostly, and we really don't need to re-ignite it, please? Smile

And if you're using an IDE it doesn't even matter in the short term. Set your project's preferences and the IDE will help you meet them, and often even reformat the entire file for you.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB