PSR-2: Add coding standards for casting and testing certain data types #40

Closed
wants to merge 2 commits into
from

Conversation

Projects
None yet

ziminji commented Jun 18, 2012

No description provided.

+type name (e.g. `bool` and `int`).
+
+```
+$b = (bool)$a;
@mhujer

mhujer Jun 18, 2012

I think that the spaces after casting operator would look better: $b = (bool) $a;

@Ph3nol

Ph3nol Jun 19, 2012

Agree about using it with a space: $b = (bool) $a;

@Marlinc

Marlinc Jul 9, 2012

Contributor

I think the same. A space after the cast is more readable.

@henrikbjorn

henrikbjorn Jul 17, 2012

It should in anycase be boolean the shortcuts dosent make sense as there isnt a short version for all types like float

@nateabele

nateabele Jul 17, 2012

+1 for one space and using full type names.

sstok commented Jul 1, 2012

+1

Member

dragoonis commented Jul 9, 2012

Looks like a good addition. I'm happy to +1 this.

Although this proposal may be better suited to the mailing list, where you can post a link back to this PR.

Thanks.

+the 'ACCESS_GRANTED' constant.
+
+```
+<?php defined('ACCESS_GRANTED') or die('No direct script access.');
@Ocramius

Ocramius Jul 15, 2012

Contributor

What is the advantage in this? A file containing a class/interface doesn't produce any output nor execute any logic anyway, except for the case when the PHP interpreter is not available.

@dragoonis

dragoonis Jul 15, 2012

Member

This is bad practise, We don't want a constant lookup and die() at the top of every file .php file..

@klaussilveira

klaussilveira Jul 15, 2012

Classes and interfaces should be outside the public document root of your webserver, there's no need to clutter the code for this matter.

@sstok

sstok Jul 16, 2012

-1 This is idea so bad on so many levels.

  1. A class file is causing side effects
  2. It will not protect against bad configured server
  3. There are much better ways of protecting these files, placing them outside the public-web root or restricting access using the server configuration.

If the file is accessed directly and will throw an fatal error, the production server is not configured properly.
display_errors should always disabled in production.

@Thinkscape

Thinkscape Jul 17, 2012

Terrible idea. It's only a cheap way of protecting class files on a poorly configured. shared hosting servers.

It goes against the principles of php-fig.

@nateabele

nateabele Jul 17, 2012

Sorry? Is this a joke? As far as I'm concerned, someone who's willing to suggest something so patently awful has no business going near any standards whatsoever.

@ziminji ziminji closed this Jul 18, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment