I've got an external standard, which I got out of Sonar. I specify the standard with the --standard=/path/to/standard.xml methodology. If that isn't a valid file, I get an error. So it is reading and parsing the file.
My problem is in the output it is including several sniffs that my standard isn't telling it to use. I get a ton of false positives going into Jenkins. Sonar at least strips out the ones that aren't in that standard. For instance, I've turned off all of the full stop rules, but they are still showing up in my report.
I am running PHP_CodeSniffer version 1.3.2.
Related
I got a problem with an API (PHP) I created. The API should create a pdf document depending on the data that is sent. The script works perfectly, running it directly on Ubuntu, Plesk is running on.
The part that is not working is the following:
$cmd = sprintf("pdflatex -interaction nonstopmode %s", escapeshellarg(file));
exec($cmd, $foo, $ret);
The tex-file seems not to be touched... no log files or anything.
Any ideas about this?
Thank you
Latex is usually run by experienced users either raw on the command line or via IDE with console interaction, since there is often the need to see from console feedback why a compilation may fail.
The Simplest check for checking is PdfLaTex installed? is at the system console to enter pdflatex --version this should confirm at least a minimal pdflatex has been found in the environment path and show the variant after a rough value for the level of pi.
So in this case responded pdfTeX 3.14159265-2.6-1.40.18 (TeX Live 2017/Debian)
When trying to run unseen it is not easy to get feed back so the smallest test with a small known sample is again at the console to run in a current working directory with batch mode :-
pdflatex -interaction=nonstopmode sample.tex
This should run with little need for checks, however if the paths to pdflatex are not configured you may need to add the location of the pdflatex executable. Thus you discovered needed /usr/bin/pdflatex -interaction=nonstopmode file.tex
There are many different dependencies in LaTeX packages and modules that require the "env" settings be well defined in terms of inter-related paths (e.g. to support files etc.) so it is worth checking those out from the extensive documentation.
Some modules may require elevation to escape shell restrictions via -shell-escape and the above command may need temporary elevation for one run (it should not be needed constantly) so only include when you know exactly from documentation why a module requires it.
It is tempting for TeX novices to think there is an advatage to use sub folder in a working directory for "chapter and verse", since the working directory may "look" cluttered by potentially dozens of runtime files, however much of LaTeX depends on very specific relative pathing and the best way to avoid errors is not need to keep redefining images or other components by variables, simply say it is in the same folder.
Likewise for the packages they should also be set to a fixed location by means of env variables i.e. for bin folder and fonts and other modular supporting components. It is worth reviewing https://tug.org/texlive/quickinstall.html and note the section about minimal path definition but there is much more than that basic setting required by post installed components
Where does PHP's NumberFormatter take the locale formats from? More interested in Linux environment, if that makes any difference.
Is it compiled in, or some system resource is used? How can I view the formats for each supported locale? (locale -c -k LC_MONETARY doesn't seem to list/have the info on the pattern.) Are they modifiable per server?
If there is a mistake in a format, where can I report it or propose a fix? (E.g., the lv_LV locale has a mistake regarding the thousand separators.)
Why is the output different for HHVM – https://3v4l.org/ms1ZN ?
PHP uses ICU library (see function unum_formatDoubleCurrency in ext/intl/formatter/formatter_format.c).
ICU library, in turn, uses Common Locale Data Repository (CLDR) (see http://userguide.icu-project.org/icudata).
The format in the example (currency format for lv_LV locale), can be seen in CLDR's Survey Tool – http://st.unicode.org/cldr-apps/v#/lv/Number_Formatting_Patterns/
If there was a bug, it could be reported at http://unicode.org/cldr/trac/newticket or edited in the Survey Tool by an account acquired in this contact form: http://www.unicode.org/reporting.html
But, in the current case, there was no bug.
The format of PHP does not match CLDR data probably because of the libicu version (and its CLDR version) that is installed on the particular computer/server, or a specific data file being used (icudatl.dat, see http://userguide.icu-project.org/icudata). At the moment (2018-09), the latest libicu/data version is 62 (see http://site.icu-project.org/home) and the latest CLDR version is 34 (see http://cldr.unicode.org/).
If icu-devtools is installed, running icuinfo would display what libicu and CLDR versions are being used. In my case: <param name="version">55.1</param>[..]<param name="cldr.version">27.0.1</param>
There are two alternatives given for the currency format in lv_LV, HHVM apparently uses the other, for some reason.
Not easy to be answered if it is not documented in the official docs. However lets have a look on the NumberFormatter implementation of PHP: https://github.com/php/php-src/tree/8939c4d96b8382abe84f35e69f4f6ebd6f0f749d/ext/intl/formatter
If you are good in C you may find the correct place I did not find it instantly (if one of us does lets replace this part of the answer).
However as far as I understand the code the correct formats are retrieved from the intl package (=internationalization package, http://php.net/manual/de/book.intl.php). NumberFormatter itself is part of it.
In case you find a real bug you can propose a fix at the official PHP Bug reporting site regarding the intl package (https://bugs.php.net/).
I'm using Phing to set up a build process for a large PHP project. I thought the stripphpcomments directive would be useful when copying files, so I added it. When I run Phing with this directive included, however, the copy process errors out with a "segmentation fault" message. After a lot of testing with exclude/include statements, I narrowed the culprits down to two files in particular -- jquery-1.4.2.min.js and a rather large HTML file.
I solved my problem by splitting my one fileset into two filesets: PHP class files and everything else, and applying the filterchain with stripphpcomments only to the first set, but I'm curious to know if anyone has run into this problem before, and what the condition is that causes the segmentation fault to be thrown. The only thing I can possibly imagine the two files above have in common is that they're both really long.
A "segmentation fault" is a crash of PHP itself. Upgrade to the latest php version (5.3.6 at the moment) and try it with that. If you still get the fault, look at #php.pecl on the EFnet IRC servers for instructions how to file a good PHP bug report.
I am looking for applications or methods for performing sanity checks of php code.
I hope to to avoid finding out about the coding mistakes the hard way, but instead find them before publishing the website.
display_errors = on and similar run-time methods find the problems too late.
So far I have found the following ways, which I think are not thorough enough:
php_check_syntax() from within php
php -l from the command line
ioncube php encoder
netbeans and eclipse as editors
What better way is there to find problems in PHP code early?
How bout unit testing? =) http://www.phpunit.de/
PHP Code Sniffer can help ensure you're writing code to a set standard.
http://pear.php.net/package/PHP_CodeSniffer/
PHP_CodeSniffer is a PHP5 script that tokenises and "sniffs" PHP, JavaScript and CSS files to detect violations of a defined coding standard. It is an essential development tool that ensures your code remains clean and consistent. It can also help prevent some common semantic errors made by developers.
Incidentally, if you want to get really into code checking, you can integrate Code Sniffer, PHPUnit and a repo together with something like phpUnderControl for automating such a process.
You could of course strip back a little and get a friend, colleague ... or dare I say it a Coding Buddy - nothing better than getting a real human being to check your code when you check it in :)
The DMS Software Reengineering Toolkit has a full PHP parser which does syntax checks. That's a big system if all you want is syntax checking.
One way to get "just" the syntax checking part of DMS is the SD PHP Formatter. This tool formats PHP code nicely. To do so, it parses it first (there's the syntax check) and then prettyprints it according to the structures implied by the PHP language rules. Of course, you could just ignore the formatted result and simply look for parsing errors.
If you like the test coverage idea, you should consider the SD PHP Test Coverage tool. This packages DMS to parse your source code, fill it with instrumentation to determine what gets executed when you run. It obviously has the syntax check still built in, as well as providing the test coverage ability.
I'm going to be doing some PHP editing for my job this summer, and am looking for an effective Emacs setup for editing it. I'm already heavily invested in Emacs, so switching to another editor is not worthwhile.
Right now, I have nXhtml-mode, which provides a PHP mode with syntax highlighting (there are at least three different ones in the wild) as well as MuMaMo for editing PHP embedded in HTML. I just started using Auto-Complete and Anything for programming and general Emacs stuff, respectively.
What I'm really looking for is an effective way to get Emacs to really understand the project, beyond just highlighting. Etags looks like a good option, but it looks like the process for generating new tags is kind of arduous and manual (or at least not invisible). The nice thing about Etags is that they integrate well with Anything and Auto-Complete. Other potential options are gtags (though I'm hesitant to install non-elisp files, just for the complexity), vtags, or Semantic, which I've messed with before and seems complicated to set up, plus it doesn't look like it has support for PHP.
Another option is Imenu, but it only works for the current buffer, and I would like to be able to jump to function definitions in other files (preferably using Anything for completion of the name).
The projects I will be working on are not that big (about 30,000 lines total), so the overhead of Etags probably won't be that big of an issue, but I'd rather not use it if there is a better solution.
So what is your preferred PHP editing system?
In addition to features you are already familiar with, I suggest you the followings.
ETags
I do not use ETags, but there is a question already on SO How to programmatically create/update a TAGS file with emacs. No good answer was posted, though, but it may be a good entry point to get an idea.
Debugging
Flymake is a mode to get on the fly syntax checking. It has support for PHP as well. It hints at syntax errors immediately as you type. The Flymake version shipped with Emacs 23 contains PHP support. If you have previous version, check Sacha Chua's post on Emacs and PHP: On-the-fly syntax checking with Flymake.
Another useful package is Geben that allows you to debug your scripts interactively. For PHP, you can use XDebug. There is a detailed tutorial on how to do that, see Debug php in emacs with geben.
Documentation lookup
PHP Mode has a nice feature to lookup the function's definition in PHP's manual in your web browser (M-x php-search-documentation or C-c C-f). You can combine it with Emacs-W3M to get the relevant manual page without leaving Emacs.
web-model.el (available on web-mode.org) handles pretty well php blocks embedded in an html document. This major mode will also highlight js and css parts.
As an alternative to ETags, consider GNU Global, aka "GTags". Global is a lot smarter about finding tags tables, and is fairly fast to update. Emacs-fu has a nice post about doing this on-the-fly.
BTW, if you're using the Windows port of GNU Global with a Windows Emacs build, use the DJGPP ("DOS") version. The MinGW ("Win32") build seems to have a problem with path names.
In addition to the answer given on May 28 '09, I think I can add some packages to it which enhanced my PHP experience on Emacs.
Auto-completion
ac-php is in my opinion a good additions to Etags. All references to a tag will be found with etags, but the definition with ac-php. ac-php is also configurable to which directories should be included. For example, while developing a wordpress plugin, you can add a reference to the directory containing the wordpress files in .ac-php-conf.json (which resides in the project root) and it will auto-complete, jump to reference, etc. This package supports company-mode and auto-complete.
Here's an example configuration of ac-php:
(use-package ac-php
:ensure t
:bind (:map
php-mode-map
("M-+" . ac-php-find-symbol-at-point)
("M-]" . ac-php-location-stack-back)
("<menu> r" . ac-php-remake-tags)
("<menu> R" . ac-php-remake-tags-all)))
Another option would be to use phpactor, but the Emacs interface is at the time of writing still in alpha stage, with which I also hardly have any experience - except for the constructor completion, which works pretty well.
Error checking
In addition to syntax errors, Flycheck supports phpMessDetector and phpCodeSniffer out of the box. This enables you to have more enhanced notice/warning/error reporting based on supported coding standard and best practices.
Another package I like for static analysis is PHPStan Emacs interface, which reports potential errors in your code (including incorrect type hints).
Additional formatting
I also use phpcbf (which apparantly is archived). This package formats the buffer into the wanted coding standard.
Semantic
For anyone in the dark, Semantic is a built-in Emacs package and provides IDE like features. Here's an example how to include semantic for php-mode:
(add-hook 'php-mode-hook (lambda ()
(require 'semantic/symref/grep)
(add-to-list 'semantic-symref-filepattern-alist '(php-mode "*.php" "*.inc"))
(semantic-mode)))
Imenu
For including imenu jumping to definitions, another example configuration:
This is the sidebar for jumping to in-file methods and functions.
(use-package imenu-list
:ensure t
:config
(setq imenu-list-focus-after-activation t)
:bind (:map php-map
("<menu> \\" . imenu-list-smart-toggle)))
Example config for helm support in jumping to definitions in all project files:
(use-package imenu-anywhere
:ensure t
:after helm
:bind (:map php-map
("<menu> |" . helm-imenu-anywhere)))
Additional debugging
Besides geben, I like to use psysh, which by dropping in eval(\Psy\sh()); gives a repl on that line of code and gives access to all definitions and whatever else one would have access to (ofcourse, after requiring it in composer).
More generally handy packages
Snippets
Maybe a bit obvious for everyone already experienced with Emacs, but yasnippet is also very handy for writing your own templates. There are also packages that include a lot of predefined templates for all sorts of languages, but I write my own to keep Emacs a little less bloated than my set-up already is, it also helps me remember them more easily.
Project management
Excuse the obviousness again, but Projectile is also a very good package which by default includes git support for scoping the project.
Offline documentation
If you use Zeal for offline documentation browsing, there's also zeal-at-point. Example configuration, if you use, lets say: PHP, CodeIgniter and WordPress:
(use-package zeal-at-point
:ensure t
:bind (("<menu> z" . zeal-at-point))
:config
(add-to-list 'zeal-at-point-mode-alist '(php-mode . ("codeigniter" "wordpress" "php"))))