4 ms·

It's like you've taken every good thing done recently to PHP and turned it on its head. Protip: You exclude closing ?> tags from your files because if there's

It's like you've taken every good thing done recently to PHP and turned it on its head. Protip: You exclude closing ?> tags from your files because if there's a new line after them, you'll get the headers already sent error, which is a big headache to track down.

contingencies 14y ago
Protip: If you're using a reasonable development process you don't have such issues. For example: file="~repo/.git/git-hooks/pre-commit";echo "#!/bin/bash">>$file;echo "find . -name *.php|xargs -n 1 php -l";chmod a+x $file # or there abouts.
- encoderer 14y ago
  Wow, yeah, you could do that. Or you could just leave off the closing tags that serve no purpose?
  - contingencies 14y ago
    Sigh. I .... can't believe an elegant solution gets downvoted and .... I have put put up with responses like this. I guess it's true what they say about the PHP community.
    - stephenr 14y ago
      how is that an elegant solution to the problem? a) you're assuming everyone uses git b) you're assuming everyone uses a cli interface to git c) you're relying on the PHP linter to identify errors. A trailing newline character is not a syntax error, it's just a potential gotcha in terms of the output that is sent to a browser. d) you're assuming that any such fix (assuming you actually removed the newlines instead of simply linting the files) has to apply to all files All of that, because you specifically ADDED extra content to the file in the first place. Seriously, what drugs create a mind state where that is "elegant"?
      - contingencies 14y ago
        > a) you're assuming everyone uses git Did I say that? No. My assumption in that (concise) means of expression was that people can understand an example and extrapolate, ie. "if you are afraid of (easily detectable problem x), use the hooks provided by your version control system". Hooks exist in [an|ever]y half-baked version control system. > b) you're assuming everyone uses a cli interface to git Hooks work through any interface... and can often be applied on the server, so they remain constant for all members of a development team. > c) you're relying on the PHP linter to identify errors No, I was giving an example. The PHP linter can surely be configured to pick up lack of a closing tag, if not then it could easily be convinced to do so. > d) you're assuming... No, again. This is an example. To re-iterate: if you want to enforce something, you enforce it programatically. You don't go around telling people to change their more-correct habits and shouting from the roof tops about how your perspective is technically superior, because, quite frankly, it isn't. I agree that not having closing tags as a coding style might be admittedly handy if you're dealing with the average (ie. low skilled) set of people and a crappy development process, but it's not something to aspire to - or defend. > Seriously, what drugs create a mind state where that is "elegant"? Drugs. Mmm. Don't want to get on to a tangent now, do we? Objectively, elegance is correctness. Good development process is elegant. In fact, it follows that elegance in process is more important than elegance in code, because it produces demonstrably correct code as a side-effect. This is the same "one level up" power-of-abstraction that code can wield on data, or LISP can wield on itself. Sorry to have to spell it out. I hope this inspires you to investigate improving your development process.
        stephenr 14y ago
        > Objectively, elegance is correctness. Good development process is elegant. So how is deliberately adding an un-needed line that is known to cause problems to the end of a file, only to have to implement a pre-commit hook in your vcs to remove it or trailing whitespace, an elegant solution. Surely the elegant solution is to not type the line in the first place.
        jtreminio 14y ago

contingencies 14y ago

Protip: If you're using a reasonable development process you don't have such issues. For example: file="~repo/.git/git-hooks/pre-commit";echo "#!/bin/bash">>$file;echo "find . -name *.php|xargs -n 1 php -l";chmod a+x $file # or there abouts.

encoderer 14y ago
Wow, yeah, you could do that. Or you could just leave off the closing tags that serve no purpose?
- contingencies 14y ago
  Sigh. I .... can't believe an elegant solution gets downvoted and .... I have put put up with responses like this. I guess it's true what they say about the PHP community.
  - stephenr 14y ago
    how is that an elegant solution to the problem? a) you're assuming everyone uses git b) you're assuming everyone uses a cli interface to git c) you're relying on the PHP linter to identify errors. A trailing newline character is not a syntax error, it's just a potential gotcha in terms of the output that is sent to a browser. d) you're assuming that any such fix (assuming you actually removed the newlines instead of simply linting the files) has to apply to all files All of that, because you specifically ADDED extra content to the file in the first place. Seriously, what drugs create a mind state where that is "elegant"?
    - contingencies 14y ago
      > a) you're assuming everyone uses git Did I say that? No. My assumption in that (concise) means of expression was that people can understand an example and extrapolate, ie. "if you are afraid of (easily detectable problem x), use the hooks provided by your version control system". Hooks exist in [an|ever]y half-baked version control system. > b) you're assuming everyone uses a cli interface to git Hooks work through any interface... and can often be applied on the server, so they remain constant for all members of a development team. > c) you're relying on the PHP linter to identify errors No, I was giving an example. The PHP linter can surely be configured to pick up lack of a closing tag, if not then it could easily be convinced to do so. > d) you're assuming... No, again. This is an example. To re-iterate: if you want to enforce something, you enforce it programatically. You don't go around telling people to change their more-correct habits and shouting from the roof tops about how your perspective is technically superior, because, quite frankly, it isn't. I agree that not having closing tags as a coding style might be admittedly handy if you're dealing with the average (ie. low skilled) set of people and a crappy development process, but it's not something to aspire to - or defend. > Seriously, what drugs create a mind state where that is "elegant"? Drugs. Mmm. Don't want to get on to a tangent now, do we? Objectively, elegance is correctness. Good development process is elegant. In fact, it follows that elegance in process is more important than elegance in code, because it produces demonstrably correct code as a side-effect. This is the same "one level up" power-of-abstraction that code can wield on data, or LISP can wield on itself. Sorry to have to spell it out. I hope this inspires you to investigate improving your development process.
      - stephenr 14y ago
        > Objectively, elegance is correctness. Good development process is elegant. So how is deliberately adding an un-needed line that is known to cause problems to the end of a file, only to have to implement a pre-commit hook in your vcs to remove it or trailing whitespace, an elegant solution. Surely the elegant solution is to not type the line in the first place.
        jtreminio 14y ago