Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy. This forum is not for asking programming related questions.
I have quite a few, I'm pretty anal about the way I do things...
1) White space...it bugs me when people use un-nessecary whitespace, like: if (
2) Mixture of variable name conventions $bettyBoop and $betty_boop
3) Inconsistent filenames (ReadMe.1st or new_user.php or UpdateUser.php
I can't stand filenames with capital letters...or spaces, use underscores...
THese are just a few...that bug me personally...in no way am I adovocating they are wrong...just personal quirks...
Hockey wrote:1) White space...it bugs me when people use un-nessecary whitespace, like: if (
I used to do it like: if(, but about a week ago I started to put a space after if's. Just want to here your pros and cons... Should I get back to my old method?
P.S I don't put spaces inside. Like this: if ( $x == 1 )
Hockey wrote:1) White space...it bugs me when people use un-nessecary whitespace, like: if (
I used to do it like: if(, but about a week ago I started to put a space after if's. Just want to here your pros and cons... Should I get back to my old method?
P.S I don't put spaces inside. Like this: if ( $x == 1 )
I use white-space in that fashion so that my source code looks less cluttered. Some people seems to have this idea that if source looks compact (harder to read IMO) then it looks cleverer. I'd personally rather write code that even a novice could pick up and "read". I'll add whitespace inside nests of parens like that if there are quite a lot of parens nested deeply... it's easier for the eyes to pair them up. If statements that only execute one line of code don't need curly braces neither IMO, although it doesn't bother me if people use them.
class foo
{
public function __construct($x)
{
if ($x == true)
{
//execute some code
}
}
}
Oh yes... I code like this too, this is much better for the eyes. It looks clean and simple.
I don't put a space between the function name and the brackets though.
short tags are probably my biggest pet peeve when it comes to php, jumping in and out of php constantly, register global issues, hiding notices/warnings/errors with error_reporting() are up on the list too.
I also find non-indented code annoying, I really don't see why people do it these days.
One big pile of undocumented mess also annoys me.
Agreed...
Code clarity I've heard, but if colorizing IDE's don't make it obvious where if starts and it's condition tests begin...your in need of a new pair of glasses is what I say
Hockey wrote:1) White space...it bugs me when people use un-nessecary whitespace, like: if (
I used to do it like: if(, but about a week ago I started to put a space after if's. Just want to here your pros and cons... Should I get back to my old method?
P.S I don't put spaces inside. Like this: if ( $x == 1 )
There are no pros' and cons I'm afraid...as it's personal preference...
However I would argue that it's simply un-nessecary...as colorizing IDE make it quite obvious where keywords begin and end, etc...
feyd wrote:short tags are probably my biggest pet peeve when it comes to php, jumping in and out of php constantly, register global issues, hiding notices/warnings/errors with error_reporting() are up on the list too.
I agree, but those are all no-no's indicating laziness or poor design or lack of experience...
I can deal with pretty much everything else since I have to work with so much random code. As long as there is some form of formatting (indenting mostly) and some comments, I'm good to go. Although the more complicated the logic, the more comments are a must for me.
feyd wrote:I can deal with pretty much everything else since I have to work with so much random code. As long as there is some form of formatting (indenting mostly) and some comments, I'm good to go. Although the more complicated the logic, the more comments are a must for me.
I can't stand when people don't comment...it's such a basic, fundamental truth of programming, that comments help...
And IMHO a lack of quality comments is a clear indication of lack of experience or naivety anyways
feyd wrote:I can deal with pretty much everything else since I have to work with so much random code. As long as there is some form of formatting (indenting mostly) and some comments, I'm good to go. Although the more complicated the logic, the more comments are a must for me.
I can't stand when people don't comment...it's such a basic, fundamental truth of programming, that comments help...
And IMHO a lack of quality comments is a clear indication of lack of experience or naivety anyways
Its like improper formatting...
Cheers
I used to write code that was ~50% comments / 50% actual code. I don't comment anywhere near as much now and I equally don't see it as a bad thing. I just write code that you can "read" and understand. i.e. Appropraitely named methods, classes and properties, don't go too far with refactoring to the point that nothing makes any sense.
If I picked up someone elses code that only had very basic comments in the odd place but I could read it like a page of text (following the logic through) then I would say that is much more professional than some manky code that I understand purely because the comments tell me what's going on... they shouldn;t need to
feyd wrote:I can deal with pretty much everything else since I have to work with so much random code. As long as there is some form of formatting (indenting mostly) and some comments, I'm good to go. Although the more complicated the logic, the more comments are a must for me.
I can't stand when people don't comment...it's such a basic, fundamental truth of programming, that comments help...
And IMHO a lack of quality comments is a clear indication of lack of experience or naivety anyways
Its like improper formatting...
Cheers
I used to write code that was ~50% comments / 50% actual code. I don't comment anywhere near as much now and I equally don't see it as a bad thing. I just write code that you can "read" and understand. i.e. Appropraitely named methods, classes and properties, don't go too far with refactoring to the point that nothing makes any sense.
If I picked up someone elses code that only had very basic comments in the odd place but I could read it like a page of text (following the logic through) then I would say that is much more professional than some manky code that I understand purely because the comments tell me what's going on... they shouldn;t need to
Thats why a professional developer strives to acheive the best of both worlds...
Exsessive comments are not good either and are often convoluted...and confusing and difficult to maintain.
I used to use a one comment for every non-obvious line of code, which typically yields about 65% code to 35% comments...
Then I switched to using multiple line comments in certain areas, like before a for loop, explaining the general idea of whats going on.
This reduced to about 15-25% comments...but I still use single line comments as well, but typically as a EOL comments, so they don't consume line space
Now I use phpDocumentor, so my comment to line ratio has shot up and function stub comments and module comments are quite lengthly...but those are easily hidden with source folding features of UltraEdit
Hockey wrote:And IMHO a lack of quality comments is a clear indication of lack of experience or naivety anyways
Not necessarily...
There is one thing many versions of PHP still has a problem with if you aren't using a precompiler like MMCache or eAccelerator. Comments.
For some reason some versions of PHP are very SLOW at processing PHP files with alot of comment lines. If you are using something like eAccelerator the comments are tossed the first time the file is processed and then only the cached/compiled code is executed. Without something like eAccelerator PHP has to bypass those lines and like I said on some versions of PHP that is very slow. You would think PHP would be able to toss comment lines faster than it could process anything else.