PHP CodeSniffer는 얼마나 유용합니까?

PHP CodeSniffer는 얼마나 유용합니까? 일반 코드 표준 시행?

---

코드 기반의 품질을 향상시키기 위해 지속적 통합 서버에 PHP CodeSniffer 를 설정하는 아이디어에 대해 생각 하고 있습니다. 문서를 읽은 후 코딩 표준을 정규화하고 적용하는 아이디어에 대해 매우 흥분됩니다. 그러나 나는 우리 제품의 실제 개선에 대해 궁금해합니다. 스니퍼가 정의 된 코딩 표준에 대한 위반 만 감지한다는 것을 잘 알고 있지만 깔끔하고 일관된 코드 기반이 제공하는 이점은 무엇입니까? PEAR 표준을 준수하기 위해 10 만 줄 이상의 코드로 프로젝트를 리팩토링하는 추가 작업의 가치가 있습니까?

일반적으로 PHP CodeSniffer 또는 코드 냄새에 익숙하지 않은 사용자를위한 예제 출력은 다음과 같습니다.

FILE : /path/to/code/myfile.php
FOUND 5 ERROR (S) 2 LINE (S)에 영향을 미치기
-
2 | 오류 | 누락 된 파일 문서 주석
20 | 오류 | PHP 키워드는 소문자 여야합니다. "false"를 예상했지만 "FALSE"를 찾았습니다.
47 | 오류 | 줄이 올바르게 들여 쓰기되지 않았습니다. 4 개의 공간을 예상했지만 1
51 개 발견 | 오류 | 누락 된 기능 문서 주석
88 | 오류 | 줄이 올바르게 들여 쓰기되지 않았습니다. 9 개의 공간을 예상했지만 6 개를 찾았습니다.

엄밀히 말하면 사용자 / 클라이언트는 표준을 준수하도록 리팩토링 된 제품에서 차이를 느끼지 못하지만 다른 숨겨진 이점이 있는지 궁금합니다.

현재 우리의 코드는 결코 엉성한 것이 아니며 대부분의 경우 Pear의 코딩 표준 에서 파생 된 자체 개인 표준을 따르려고 노력 하지만 훈련 된 눈으로 차이점을 알아볼 수 있습니다.

그래서 제 질문은 그들이 제품의 품질을 얼마나 향상 시키는가입니다. 그로 인해 어떤 종류의 잠재적 인 이점이 있었습니까?

우리 제품을 일련의 표준에 더 가깝게 만들고자하는 열망에 강박적인 것일까 요? 그만한 가치가 있습니까? 그렇다면 코드 스니퍼를 구현하고 발견 된 후속 위반을 수정하기 위해 어떤 종류의 전략을 사용 했습니까?

---

첫째, 저는 PHP_CodeSniffer의 메인테이너이므로이 분야에서 분명히 편향되어 있습니다. 하지만 저는 PHP 개발자로 10 년 동안 몇 가지 큰 코드베이스를 작업 해 왔기 때문에 코딩 표준이 좋은 이유에 대한 구체적인 이유를 제시 할 수 있기를 바랍니다. 이 주제에 대한 블로그 시리즈를 쓸 수는 있지만 PHP_CodeSniffer가 어떻게 생겨 났는지에 대한 간단한 이야기를하여 도구가 저를 위해 해결 한 문제를 이해할 수 있도록하겠습니다.

저는 몇 가지 큰 CMS 프로젝트를 진행했습니다. 첫 번째는 그 뒤에 많은 코드와 상대적으로 작은 개발 팀을 가지고있었습니다. 우리에게는 기준이 없었습니다. 그러나 우리는 진짜 문제가 없었습니다. 팀은 작았고 꽤 오랫동안 함께 지 냈습니다. 우리는 서로에게 익숙해졌습니다.

그런 다음 새로운 CMS를 구축했습니다. 우리는 단지 몇 명의 개발자와 함께 새롭게 시작했습니다. 당시 저는 두 명의 개발자로 구성된 팀의 일원이었습니다. 다시 말하지만, 코딩 표준은 우리에게 문제를 일으키지 않았습니다. 나와 다른 개발자는 같은 배경에서 왔으며 이미 우리가 따랐던 몇 가지 지침을 수립했습니다. 당시에는 PHPCS가 필요하지 않았습니다.

그러나 그 팀은 한 번에 개발자를 성장 시켰고 결국 12 명의 정규 개발자가되었고 상당수가왔다 갔다했습니다. 일부는 이전 CMS에서 왔고 일부는 회사 외부에서 왔습니다. 모두 다른 배경과 개발 방식을 가지고있었습니다. 스타일이 너무 다르기 때문에 누가 어떤 코드를 작성했는지는 분명했습니다. 복잡한 작업을 할 때마다 코드를 보는 데 익숙한 방식이 아니기 때문에 먼저 스타일에 적응해야합니다. 처음으로 셰익스피어를 읽는 것과 같습니다. 자연스러운 속도로 읽기 전에 익숙해 져야합니다.

개발자들에게 다른 코딩 스타일을 멈추고 파악하는 데 필요한 추가 시간은 순수한 낭비 일뿐입니다. 간격, 들여 쓰기 및 브래킷 위치로 인해 수렁에 빠진 ​​동안 아이디어가 빠져 나갈 기회입니다. 결국 이러한 것들은 중요하지 않습니다. 하지만 말씀 드리면 개발자가 흐름을 깨뜨리는 경우에는 매우 중요합니다. 그래서 우리는 그들이 길을 잃고 개발자들이 최선을 다할 수 있도록하는 방법이 필요했습니다.

동시에, 우리는 훨씬 더 많은 자바 스크립트를 파헤 치고있었습니다. 스타일이 일반적으로 창 밖으로 던져진 새로운 언어. 예제 사이트에서 코드를 복사 / 붙여 넣기하고 함께 으깬다. 새로운 언어로 복잡한 코드를 개발하는 방법을 배울 때 JS를 PHP와 비슷하게 만드는 방법을 찾는 것이 합리적이었습니다. 나중에 최소화 할 수 있지만 흐름을 유지하기 위해 언어간에 빠르게 전환 할 수 있어야했습니다.

그래서 PHP_CodeSniffer는이를 위해 태어났습니다. 개발자가 동일한 코딩 스타일로 작업하여 서식 및 기타 화염 미끼 문제를 완전히 제거 할 수 있습니다. JS를 PHP처럼 어느 정도 취급 할 수 있습니다. 번역되지 않은 문자열이나 적절한 클래스 포함 코드를 사용하지 않는 개발자와 같은 제품 별 냄새를 감지하는 데 사용합니다. 또한 IE를 죽이는 JS 쉼표가 남아 있지 않은지 확인하는 것과 같은 언어 별 냄새에도 사용합니다. 원하는대로 사용할 수 있습니다. XML 규칙 세트 파일을 사용하여 쉽게 병합 할 수있는 스 니프 힙이 함께 제공 됩니다 . 직접 작성할 수도 있습니다. 타사 도구를 통합하여 정적 코드 분석을위한 원 스톱 상점으로 만들 수 있습니다. 표준 및 코드 냄새에 대해 원하는만큼 심각 할 수 있습니다.

다른 개발 도구와 마찬가지로 PHP_CodeSniffer가 작동합니다. 당신은 그것을 위해 일하지 않습니다. 신경 쓰지 않는 오류가 너무 많이 생성되면 표준을 사용자 지정하여 원하지 않는 오류를 제거하거나 오류를 경고로 전환하십시오. 그러나 내 이야기가 당신이 겪고 있거나 미래에 겪을 수있는 것처럼 들리면 PHP_CodeSniffer를 자세히 살펴보고 도움이 될 수 있는지 확인하는 것이 좋습니다.

여러분과 다른 사람들이 코딩 표준이 일부 프로젝트와 개발자에게 정말 중요한 이유를 이해하는 데 도움이되기를 바랍니다. 세부 사항에 관한 것이 아닙니다. 개발자가 집중력을 잃게 만드는 요소 목록에서 코딩 스타일을 제거하는 것입니다.

---

Having coding style conventions is a good idea, because it helps developers not get distracted by code written in a different style when working on code they did not write. It will make your code base superficially cleaner. It's great if you can automate it, but there is usually no need to go through great lengths to comply (unless the current style is terrible). If you already have a good-enough standard, stick to it.

Code smell is something different though: it is (a set of) symptoms that may indicate a deeper problem with the code. Examples are cyclomatic complexity, long method names, large classes, undescriptive names, duplicate code, etc. This is usually much more problematic, as it may thoroughly hurt the maintainability of your code. You should definitely solve these problems.

PHP CodeSniffer appears to be mainly developed for checking style conventions, not code smell. If you can use it to help enforce style conventions, great. But beware that it will not make your code base substantially better. You will want to do manual reviews to accomplish that.

If you want to use it to check if you comply to your current standard, that appears to be possible, see the answer to the question "I don't agree with your coding standards! Can I make PHP_CodeSniffer enforce my own?" in their FAQ.

---

Count me in among those who evangelise CodeSniffer. After being highly sceptical for years, I now use it on every project I'm working on. Why?

As Grace Hopper and/or Andrew Tanenbaum famously said,

The wonderful thing about standards is that you have so many to choose from.

Likewise, it's almost always a Bad Idea™ to create your own coding standard; creating one comprehensive enough to cover all your code is hard, and, much more importantly, it will not be to the liking of the next person to maintain your code, who will try to "improve" your standard so that it suits his long-held coding style. Adopting an appropriate outside standard, whether it's Zend or PEAR or Kohana or JoeBobBriggsAndHisFifthCousin, allows you to concentrate on the content rather than the formatting. Better still, tools like PHP CodeSniffer either support the standard "fresh out of the tin" or those who have gone before have almost certainly implemented support as an add-on.

Mixing coding standards with existing code not written to that standard will give you fits, unless you adopt two simple, complementary rules.

Exclude files which predate your adoption of the coding standard from being checked, through the --ignore command-line option or equivalent configuration-file settings. But, when you do modify any part of a source file, update the entire file to comply with your chosen standard.

I just wrote a new blog post about this sort of thing.

---

There are lots of cases that require human judgement, and CodeSniffer doesn't have one.

Consistent brackets, indentation improve the code. Lack of space after commas in function call? Probably can be forgiven, but that's ERROR according to CodeSniffer.

IMHO there are way too many errors reported by CS. Even projects that appear to have neat code can easily run into thousands of CS issues. It quickly becomes tiring and nearly impossible to resolve all those issues, especially when it's a mix of real problems and obsesive-compulsive nonsense — both equally often marked as ERRORS.

You may be better off ignoring CS and spending time on actual improvements to the code (in terms of design, algorithms) rather than just completely superficial whitespace and comments changes (does 1-line isAlpha function really need 8 lines of comments? Yes, if you ask CS).

CS can too easily become turd-polishing tool.

---

This is definitely a good thing. We run ours from an SVN hook so that all code has to pass the house standard (a modification from PEAR) before it can be committed (this was one of the best decisions I ever made).

Of course, this works best for a new project, where there isn't loads of legacy code to convert to the new standard. One way around this is modify your SVN pre-commit hook to only run new additions to the codesniffer and to ignore modifications. You can do this by adding the line:

$SVNLOOK changed "$REPOS" -t "$TXN" | grep "^A.*\.php " > /dev/null || exit 0

This will exit the hook script if there isn't a new PHP code to parse. Hence all new files will need to obey the standard and you can bring the legacy code up to the standard in your own time.

---

Note that if you are using Eclipse or Zend IDE you can benefit from automatic tools that makes the respect of a standard less costly. You can also use a continuous integration tool like Hudson or PHPUndercontrol.

• PDT is a cool editor for PHP
• PDT-Tools are some plugins for PDT with an automatic formatting tool
• DTLK (Dynamic Toolkit Library) can be used to launch some external scripts to check your files.

You can also have a look at PHP Checkstyle which I think is easier to configure (disclaimer : I've worked on it)

Some other tools are listed on the "documentation" page of the web site.

---

CodeSniffer is a great thing to implement, but you have to know how to use it. Unless you have to comply with a given coding standard because you are submitting your work to some external project, you are free to completely define your own coding standards.

PHP CodeSniffer should make this very easy for you, because there are already many single code sniffs that you can include in your own coding standard definition and need not write them from scratch. While exploring the possibilities of the existing Codesniffers, you might end up writing an extension to an existing sniff or one sniff on your own, if you feel the need.

If you want to start with CodeSniffer, first step would be to grab a set of sniffs that completely resemble your current coding standards, and check the resulting errors and warnings. Don't apply one of the predefined standards, as this will most likely result in too many errors with too few benefit if fixed. For example, if you do not use PHPDoc to generate a documentation, it would be no use to fulfill all the codesniffer errors about missing PHPDoc tags and comments.

---

Are you providing PEAR packages for public distribution thru PEAR/PECL? If so then you probably want to stick to PEAR conventions.

Otherwise, I can't see it being worth the big refactor. The biggest thing is agreeing upon a coding standard for your team... doesn't have to be PEAR's standard... just make sure there is some standard convention enforced.

For instance, I'm a fan of the

function foo () {

format vs the PEAR standard..

function foo ()
{

Bottom line, don't worry too much about conforming to their standard if its going to be a ton of work, especially if you aren't putting the packages on PECL.

ReferenceURL : https://stackoverflow.com/questions/982333/how-useful-is-php-codesniffer-code-standards-enforcement-in-general