Smashing Magazine - we smash you with the information that will make your life easier. really.

great!!

nice article

Dropping the brackets is a great way to make your code less readable. It’s a stupid tip.

I see some bad ideas here. Applying the techniques #4, #6 and #9 will result in lesser readable and maintainable code. A little sidenote concerning performance: It is better to write good code and use caching techniques to increase performance.

Some of these tips are micro-optimizations while others are universally useful. I want to add a couple things to the mix:

- Upgrade your PHP installation to the latest version… currently it’s 5.2+. This way, you can be certain that your server has the latest bugfixes.
- Use an opcode cacher, like APC, to speed up your execution time. Opcode cachers saved compiled versions of your scripts, so they don’t have to be compiled every time they are run. This will make any PHP site much faster.
- Use the mysqli class that comes with PHP 5 instead of the old mysql. This allows you to do object-based queries with bound parameters, which prevents SQL injection by ensuring that every parameter will be checked and forced to be an integer or a string, and will then be contained within the query, even if they have quotation marks injected.

But the most important tip I can share is, always be learning!

Tips 3 and 4 are really bad. It’s much better to use certain coding styles.

I like this article, it points out a regular problem : performances vs legibility.

Personally, I always drop the brackets when I can (meaning : a short test and a single short consequent). I know this is considered to be less readable, but if it is the case, it’s probably that this is the consequent (or the test) that isn’t readable enough, not the conditional form itself (providing you use a good indentation).

On the other hand, #10 seems to be definitively tricky when you read it.

@matt : I agree with you, but here, it is to use caching techniques *and* to write fast code. The audience must be extreme speed requirement applications.

I don’t agree with tip 4, dropping brackets make code less readable.
I use sometimes ternary operators, but also this tecnique make code less readable.
I’ve never tested a code with brackets an without brackets, but I don’t think that the results are so different.

Reguarding tip #9, I don’t know what was in the writer mind, but without an explanation this could lead to unwanted results:

$a = 5;
$b = $a;
$a = 10;
echo $a."-".$b; // 10 - 5
$a = 5;
$b =& $a;
$a = 10;
echo $a."-".$b; // 10 - 10


For other tips, some are ok, some are banal.
I suggest to change the article title in to 10 Advanced PHP Tips To Improve Your Programming (not so much)

Great but you should rename the post to:

“6 adavanced tips to mess up your code!”

Agree with the previous posters, there are some dreadful tips here. Shorthand else and dropping braces do nothing but decrease the legibility of your code.

Shorter code in terms of short cuts like these are not a sign of good code. “Anything that can be done to make the code simpler and smaller is usually a good practice” is a terrible generalisation. Far better practices to adhere to are following OO programming principles that encourage reusable, modular code.

Furthermore, the article is contradictory – it encourages you to use a framework, but those frameworks have coding standards that automatically invalidate these two rules! For example, the Zend framework states: “PHP allows statements to be written without braces in some circumstances. This coding standard makes no differentiation- all “if”, “elseif” or “else” statements must use braces.”

This article is a good idea, but has been poorly thought out.

“Drop those Brackets” is a bad tip…

Actually thee difference between single-quote ‘ and double-quotes ” can add up over an entire application. For example, the command:
$var = 'Test';
$st = "This is a string called $var";
vs.
$st = 'This is a string called ' . $var;
in the first line, the string will be parsed for variables and then they will be evaluated. In the second line the two strings are concatenated. The second can offer some speed advantages. Even if the first string did not contain a variable it would still be evaluated for variables.

In cases where you use a string as an index (in an array for instance) you would find that
$my_array['keyvalue'] would be more efficient than $my_array["keyvalue"]or (heaven forbid) $my_array[keyvalue].

If you do a lot of string wrangling (in localization for instance) you will notice a difference in speed.

Sorry, but 3 and 4 are definitely bad advice. 6 has some nice applications, where it really looks better, but I wouldn’t overuse it either, especially with lengthy conditions and value assignments.

You should apply #6 to #3:

$x = (this condition) ? 5 : 10;

It only makes one assignment (unlike the “shortcut” version), and requires even less code. I realize people have mixed views on the ternary operator, but it’s honestly only confusing to people who refuse to use them.

Thanks. PHP tips are always welcome!

Dropping the curly brackets, is very stupid, it makes the source less readable, and very easy to make mistakes, if you’re going to add a code line to that part of the sourcecode.
So my tip would be, Use curly-brackets all over..

Drop the brackets: All I can say to this one is, NO! As a young programmer I’d omit the brackets all the time if it was only 1 line. But then what happens if you discover later on you need to do more stuff based on your enclosing condition? Now you have to add the brackets back in. As code gets more nested the readability tends to go down and if you fail to enclose your 1 line statements in brackets the situation only gets worse. A much much better tip would be, “Always use brackets, even if they only enclose 1 line of code”.

The else statement tip has issues too. The if – then – else form has the advantage that the variable only gets set once. In the no else case, the variable can be set twice if the if condition is met. If you have an expensive function where the variable set is instead then the no else approach can get very costly. It also reduces readability as the logic tree the programmer is implementing can be obfuscated. If you see an if … else in a piece of code it’s obvious that there’s a “fork in the road” at that point where one of two blocks of code will be executed. This isn’t so obvious in the no else case. The size of the PHP script has no bearing whatsoever on the size of the output and the longer versions are more readable, and the poor bastard who has to come along and maintain your code in a few months time might just be yourself. It’s amazing how much you can forget about your own code if it’s not crystal clear what it’s doing.

As for the final tip, this one carries an important caveat. You’re using a function for a job other than the one it was intended for, so be sure to leave a comment in your code explaining this. And while it might be five times faster, the time difference is probably not going to be noticeable unless you’re processing massive amounts of data in a loop. Beware premature optimization.

The biggest performance hit you’re going to take in most PHP applications is almost certainly going to be the cost of talking to your database. My advice here is to treat talking to the database as if you’re looting for supplies in a zombie move – Get in, grab only what you need and get the hell out. The more queries you perform the slower your application will be, the more data the database returns in response to a query the slower your application will be, and the general rule is you’ll be doing far more SELECTs than you will be doing UPDATEs, INSERTs or DELETEs. If data doesn’t change often then cache it and avoid the database query altogether.

This post is full of inaccuracies and misleading advice. Here’s a breakdown of the more eggregious offences:

4. Drop those Brackets
First, they’re braces, not brackets. Brackets are used in array notation ([]), braces ({}) are used for blocks.

This is actually a really, really bad idea when it comes to maintainability. Dropping braces makes it more difficult to read code, and to determine when the conditions stop and execution resumes. When you need to add extra statements, bugs can creep in if you forget to add the braces. There are good reasons why every sane coding standard requires that you use them.

5. Favor str_replace() Over ereg_replace() and preg_replace()
While I agree with this, the last sentence is misleading: “If you’re using regular expressions, than ereg_replace() and preg_replace() will be faster than str_replace().” str_replace() does not allow regular expressions, period. If you’re using regular expressions, you should use preg_replace(). (The various ereg functions are being aliased to preg functions starting in PHP 5.3.)

9. Use the Suppression Operator Correctly
The correct way to use error suppression is to not use error suppression, plain and simple. Unless you really, really know what you’re doing and have a good reason to use it, in most cases it will simply mask error conditions and make debugging harder.

Furthermore, the examples shown are poor. Use the ternary: $albert = isset($albus) ? $albus : null; This is equivalent to the first example, which, other than lack of braces, is reasonable. The other two are poor; suppressing errors is bad, and the last example, assigning by reference, is almost certainly not what the user would desire (as updates to $albus would then update the value of $albert).

10. Use isset instead of strlen
This example is entirely misleading. isset() checks to see if the variable exists, plain and simple. Even if the value is null or an empty string, it will return true. If you are testing for the minimum length of a string, strlen() is the appropriate function to call.

@aditia:

Your friend would be better off adapting to a framework. I was the same way. I had my way of doing things for the longest time. My setup was surprisingly similar to Zend minus the MVC setup (which is optional).

In the end, frameworks offer one thing that your own code doesn’t. Testing. Zend is tested through and through. Some immature components (generally in pre-release/preview versions) will have a few minor bugs… but once they get to a full release version, the bugs are generally gone. Zend is tested through unit tests, and through 1000’s of sites that employ it. Updates are frequent enough to stay current, and spaced enough to provide adequate testing time before full release.

Like I said above, it should be the opposite (it never will be, people always look for the easiest path)… new developers should write their own code, experienced developers should use frameworks.

By the way, a good case for ternary operation is zebra-striping tables.

ex:
$class = ($class == 'row_odd') ? 'row_even' : 'row_odd';


If your classnames use numbers, you could easily use modulus to do it… but normally i don’t like using numbers in class names in my css

great article. :D love it. keep on smashing us

nice article

I know very little PHP and want very much to start learning. Based on the comments it would seem that this article in general is feeding me bad advice. Not good for anyone trying to absorb knowledge. I often look to Smashing Magazine and the like to inspire and help my development skillset.

Smashing, please don’t be responsible for the bad practises that would result from someone like me reading this type of post. I don’t want to start my PHP adventures off badly. It’s a good thing I always read the comments from the smarter people in the room!

Thanks to all you responsible and insightful commenters for keeping us lesser humans out of danger. Keep fighting the good fight!!

Whoa, no response from SM, yet? Amazing :|

Wow. Shortcut the else? lol Okay, that’s definitely not good advice. That’s an example of being too clever for your own good.

Forget Tip #4.

That is one of my pet peeves. Never leave out the braces. While on the surface it seems to save time it actually creates further problems.

First and foremost is readability. In 6, 8 12 months when you come back to your code you may very well spend an inordinate amount of time trying to figure out what you were trying to accomplish. Then there’s the case of someone else who may need to work on the code you created. They’re going to be wasting time as well.

And finally as Matthew Weier O’Phinney pointed out, there’s the issue of bugs creeping into your code.

Usually SM’s articles are great, but this one borders on the irresponsible.

This is really a bunch of pretty wildly mixed tips.
Tips like memcached or using a framework are certainly only useful for more experienced developers.
Those however, would never drop common coding guidelines and readability to weird code that’s faster written or shorter as in lines.

Ternaries are sometimes useful, however when having a quick glance at your own code, you’ll never really interprete them as fast or correct as a proper if/else statement. Same goes for the tip of avoiding the else at all.
And never ever nest ternary operator statements.

For unexperienced programmers writing smaller applications, it’s definitely overthrown to use a framework or to consider using memcached aswell.

I’d say those tips should be regarded critically and i’d love to see a followup correcting that.

As both a web developer and a desktop software engineer, I’m really surprised that this article made it through the doors of Smashing. None of this is advanced by any stretch of the word. Some of these tips are for beginners (such as learning operators for a language) and some of these tips are just plain inaccurate or bad.

Unfortunately, the creed of minimizing file size on the web to promote fast load times has forced itself upon the development community, leading us to believe that if we remove brackets and else statements, we will somehow see a performance increase in our web applications. For example, tips 3 and 4 have NO affect on performance because if statements inherently add on constant-time performance (unless nested with for loops or while loops). Actually, 4 might have a DETRIMENTAL affect on performance because you are assigning a variable at most twice, whereas with if/else statements you assign a variable at most once, but regardless is a NEGLIGIBLE and irrelevant factor that cannot be associated with performance.

Also, if any of you have ever written in C/C++ before, you would know that tip #9 needs WAY more of an explanation of the consequences of using references. Are PHP references like C references? Not totally, because PHP references do not access the same address space. Nonetheless, they borrow the idea of pointing two variables to the same object content. =, replaces the ‘destination’s value; =&, changes the destination. So in a true computer science definition, references aren’t really referencing anything, and you are wise to avoid them at all costs.

And I complete agree with Matt Weier on #10 – two functions used for two totally different purposes.

This is disappointing.

Laaangweilig!

As people said, these are not “advanced” tips. But I think they work for smashingmagazine because it’s primarily a design blog, so a lot of the people coming here are not seasoned programmers, maybe involved on the light side.

Also as people commented, don’t drop brackets to make the code smaller or a one liner. Better to just minify code on a production server and leave development code easy to understand and more inline with other languages.

I agree with Joshua M. This website smashes people with web design stuff :D But it sucks in programming stuff.. hehe :)

but anyway, tips are just tips, so let’s just read the tips if we want, follow the tips if we want, and apply that tips if we want. If we don’t want, then it’s up to us :)

@ kevin: “PHP is very powerful language, much more powerful than your stupid microsoft p
platform. Do some research on it.”

not sure what you mean with “power”, if it’s performance .NET wins by far, if it’s a proper language, then microsofts C# is probably the most respected language nowadays, if it’s about libraries and community, then C#/.Net have some of the most experienced programmers (and nearly no kiddies).

so, please explain me what you mean with PHP’s “power”.

@ kevin: “The point is whatever language you are using, it depends on you and you only. If you are a bad programmer, your work done will be bad. You can use any language you like. We got many options.”

haha, no. this is only the case with php. any other serious language does not allow you to code so much crap (at least with such a freedom). you ever tried any “real” language (Java, C#, ada, eiffel, pascal)? i don’t think so, because you would know it better.

that “it’s all in the programmers hands” is stupid and a specific PHP and assembler (!) topic, it has nothing to do with state of the art programming. there’s a reason why PHP has so may frameworks – the fundament highly encourages bad coding style (well, it nearly forces people to write bad code).

mmm, i don’t think so, not too usefull.
I’m working on a Web design company, and every time a have to checked somebody else’s work and he “drops the braces” i want to punch him in his face.

I think all this “tip” were made for the very same guy who creates the sprintf() instance. Not usefull, very not readable & complicated.

I’ll give you a very nice tip, do your work as commented and long as you can, don’t mess with the braces or the elses or anithing else, you will be thankful later.

PD: other tip, if you’re novice on php and you wants to ease you work, don’t waste you time on this kind of articles, it will confuse you more. http://www.php.net will help you more!

Actually I think that the ternary operator “can” be useful at times, but you really have to be careful when to use it.

And for “dropping the braces”… this is a big NO. I have to maintain some code right now by somebody who did this all the time. It’s a horror to read…

My tip: Use braces all the time, with proper indentation. If you have too many levels of braces, use new methods (with intuitive names) to capsule the code. Keep the structure of the code always in a way, that you can understand the meaning behind it with a short glance.

This is horrible advice… seriously. Dropping brackets severely reduces legibility and leads to other problems for novice coders like not knowing that when the brackets aren’t there, only the next single line of code will be based on the conditional statement. How did this article get published?

With PHP5, you should almost never use the assignment operator, and absolutely SHOULD NEVER use it to avoid errors!

2 ACTUAL tips to better code:
1) Code to the Zend Coding Standards
2) Turn ON error_reporting to E_ALL | E_STRICT

This article is extremely misleading…

Since these “Advanced” tips appear to be aimed towards newbie PHP programmers, I thought I’d mention another useful tip:

$mynum = $mynum + $num;

is equivalent to

$mynum += $num;

But my best advice to any newbie PHP programmer is this: look at and read lots and lots of open-source PHP code written by professional PHP developers. If you don’t understand something, read the manual on php.net (use the search box to find functions) and try to understand why things are done the way they are.

There are dozens and dozens of good open-source PHP projects that you can learn from (WordPress, Gallery 2, etc).

Half of the advice in this article is garbage, not because I don’t agree with it, but simply because the fact this article is suppose to be about “improve your programming” and half of the points here are purely cosmetic/style choices.

Dropping brackets, ternary and shortcutting if/else doesn’t “improve” code, it’s purely a personnal choice but I’m not a fan of any of these because readibility is more important than reducing the number of lines. None of these changes will affect the speed or memory usage of your application. Too many coders already produce unreadable code, anything that makes code more illegible is a bad thing.

This whole article reeks of some poor concept that less lines of code is absolutely better. While less code means less testing, using the frameworks were a great idea,

Ultimately, this article doesn’t satisfy what the title lays it out to be about, this is more of a “the way the author codes”, this could have been a much better article.

Article blows. This is not useful for advanced users. This is not even useful to intermediate users because the advice is bad. For example: don’t get rid of brackets– most programming standards mandate brackets.

“Tip of the day! Use ASP.NET/C#.NET” – lol, not really a solution is it?

Yeah not all of these tips are brilliant but most of them are useful for beginners. One of the best things you can do to improve your code is to download one of the frameworks and study them. Also look in to design patterns for improving code and making maintenance easier.

Also, I recommend commenting your code. Sounds obvious but when you are working on code that makes sense at the time, when you come back to it the reason for the code may not be immediately obvious. Save yourself and fellow developers time by commenting, you’ll be grateful you did!

TIP #11: DON’T GIVE CODING TIPS WHEN YOU’RE A GRAPHIC PRO.
All caps yeah.

good article, thanks!

To be blunt, some of this advice is bad and still more is trivial. However, the vast majority of the comments here appear to be from those whose coding ability comes at the expense of all traces of social skill, namely civility… and people wonder why programmers have a reputation of being awkward, girlfrend-less shut-ins?

I find code readability and long term maintenance is enhanced by using brackets and avoiding ternary operators. Just my opinion. For one line assignments, I like the tip on avoiding else statements. Nice. Anything more than a one line assignment and I would keep the else statement for maintenance and readability.

Tip #4 looks like something out of the Daily WTF. Avoid being cute and clever at all costs.
JIm, ColdFusion Developer.

duh. noob article.

turd cassarole.

frameworks slow down small site development by the way.

Tip #3 is really bad advice in terms of readability. If you want to do something when a condition is false use the ELSE statement, not a completely disconnected expression outside the if/else

Advising dropping the braces on a one-line block (in pursuit of “quicker, leaner code”) is about equivalent to advising the use of very short variable names. That is, it’s equally stupid.

in reference to using the ternary operator – I have to agree to an extent with the comments stating it makes debugging/reworking code more difficult… but I feel there’s a bigger issue at stake which is speed

A benchtest I ran a little while back shows the speed comparison between the ternary operator and longhand if/else statement – ok I admit it’s only a 2.78% speed decrease for the ternary operator – but shows that shorter code doesn’t always equal better speed.

Article title is misleading. Some of these tips are reserved for entry level programmers. I strongly feel that programming articles like these be okayed by someone who actually knows his stuff before publishing on the web.

I liked this article. I hardly work on php coz m a flex developer, but after reading this article and its comments I could borrow a lot of guidelines and points that could be helpful to programmers in general.

I agree with comments on paranthesis and braces. Its a good practice to have them. It makes the code readable and also there is always a possibility of adding more code inside your conditions.

There is one more point I can add to this list. While using loops its better not to use expressions inside the loop condition, the value for which is going to remain constant throughout the loop.

for example:

while(i < names_array.length) {}

is same as

var namesArrLen = names_array.length;
while(i < namesArrLen ) {}

but more optimized.

Nice Article…. Thanks You!

Advanced tips? I’m sorry, but if you have trouble understanding SQL injection, comparison operators or the difference between str_replace and ereg_replace, you’re an amateur. You shouldn’t read this article. Instead, read a professional tutorial where good practises are explained.

Also, the tips are a random collection of bad practises, I-already-knew-that’s and who-the-beep-is-doing-that-anyway’s.

Thanks for the efforts, Glen, but next time you’re writing an article, please know what you’re talking about.

Great as usual, but in 1. item name is Ferruh Mavituna…

@Jonesy: You appear to be confusing your boolean operators.

Losing brackets makes it hard to read, but alternative syntax does exist for control structures.
Namely replacing the opening bracket with a colon then utilising the ‘endif’:

if ($a == 5):
echo "A is equal to 5";
endif;

This does help punctuate control structures where a closing bracket can occasionally be confusing. Works with for, while, ifelse etc.
That said I use brackets, and I find the ternary operator useful in some instances.

for the 3rd tip I’d use this ;)
$x = (condition)?5:10;

#3, #4, #6 and #9 are all bad techniques. And will not save any noticeable time when running the app at all.

Your actually teaching the new kids the bad habits of the old dogs. Code should be readable, if you want to teach a great technique teach the importance of proper commenting in your code and the importance of consistency.

This article really let me down.

I just recently found SMM, but in the short time I have been going through the articles, almost all of them have contained invaluable information except this one. If you are a new programmer, please ignore this article and read the comments. I make my living fixing botched programming jobs, but nothing is worse than someone who has only a rough grasp of how to program, trying to streamline their code. If you don’t know what refactoring is please do not write an article on how to optimize your code. None of these tips will help in any significant way. Cache your code and if you are still not seeing enough performance, hire someone to help.

DONT USE A FRAMEWORK… most of them have too much overhead.

Believe it or not MOST of the time you get things done faster because you know YOUR OWN code over others and its a waste of time learning someone’s code (large code might I add)…just time consuming.

Try your best to stay away from frameworks.

Lol, we still use Coldfusion but I think we will still take a lot away from what has been mentioned here.

Great post, dugg.

From the Couch

This article should read x Comment Tips to Improve This Article

LOL.

I love the braces! Don’t wanna lose them.

Why are so many “developers” here afraid of frameworks?

@123 Ivan:
As a developer I do use a framework, but I wrote my own (which most developers have done). It’s not that the existing frameworks are bad or can’t do what I want, but when you need a very simple script or need something that isn’t in the framework you need to hack around it to make it work properly… which means more coding and even more debugging.

I also note a lot of comments about tip 3, 4, 5 and 6; I use this way of writing for 2 reasons:
1) it’s easier to write, which means faster coding
2) it’s shorter in code, which means faster code (not with one execution, but think in millions)

At last! With these tips at my fingertips I feel like I can handle anything.
Seriously, the only thing that is more useless than these 10 tips is me commenting them.

Yup, great article. Especially #1… Thank you.

Oh dear. I’m basically repeating what everyone else has already said, but a good half of these tips are really really terrible practises. First year CS courses should beat this kind-of behaviour out of people. I guess PHP programmers don’t do CS courses anymore :(

I expected some.. well.. advanced stuff. This seems still basic to me, but anyway…

I do not agree with tip #4. As much as I despise brackets, applying tip 4 to your code makes it less readable and more error prone. Sticking to a Coding Convention like Zend’s or Pear’s is a much better advice, if the only aim is improving code readability.

Since you mention the Ternary Operator in #6 and claim improvement in code and performance. The Ternary operator is slower than the equivalent if/else statement. But I agree it can improve code readability if not used for lengthy code blocks, which would reduce readability.

As for #8 “A Framework does help eliminate some of the overhead in developing Web applications and Web services.”: Well, I think the decision to use a framework should depend on the task at hand. They might just as well add much more overhead than they eliminate. And I can’t believe you advocate frameworks and dont even mention Pear.

Nice article. Thanks for the tips….

Oh Gawd!!!! Now I’m the first to admit that I’m a total & utter php virgin (Apart from a little bit of fiddling, successfully I might add, with some WordPress code) this article is such a TURNOFF it’s like trying to read a mongolian lawnmower manual. Jeez, it’s nurdtastic guff like this that KILLS any inspiration stone cold dead in it’s tracks. “Code is poetry?” Don’t make me laugh, it’s a right royal pain in the butt. Yeah php apps tend to be way cooler & superior in functionality, certainly in relation to the all that sad asp b0770cks, but give me Photoshop, a slice tool and the resulting simple html anyday. Death to the nurds I say DEATH TO THE NURDS!!!!

ColdFusion is still #1 in my book. And there are free versions of the CFML engine now available.

Useless. It does nothing for home country.

nice tips

to be fair, if you are using regular expressions where you could be using a str_replace – then that’s a mistake in itself… there are certain things that you can do with regular expressions that you can’t with a str_replace, its not an either or situation – they are for different tasks.

(Reply to comment #6, #10)
There is a huge difference between “ and ‘ . Double quotes scans for variables inside the string and interprets them (replaces them with the value). While single quotes do not consider variables inside the string, and thus returns the string as is.

stop writing articles on matters you don’t know shit about. You are leading people, who are trying to learn PHP in a completely wrong direction. Some of the tips are unneccesary and most are simply bullshit.

yours
theFreakus ;)

i agree with them all except for dropping the brackets…. that can lead to alot oh headaches and makes the code alot less readable. id rather spend the .05 seconds pressing that extra key than have to sort through a ton of code looking for the line i want

USEFUL !!

I’m sorry but the understanding of the “===” Operator or the beware of SQL-Injections are Advanced PHP Tips?? wth?

Whats about Class-Autoloader, use of Design Patterns, the use of phpdoc comments, and the reading and understanding of the infamous paper from the owasp, “top 10 security issues in web applications”? I think that are better Tips then yours for PHP Developers.
Most of that are Code-Design decisions and its obvious for every big project to create Code-Design-Guidelines and they would forbid the most of your “Tips”.

Ternary operators are bad, period. The proof is in the article itself. The author states that:


$todo = (empty($_POST[’todo’])) ? ‘default’ : $_POST[’todo’];


is identical to:


if (empty($_POST[’todo’])) {
$action = ‘default’;
} else {
$action = $_POST[’todo’];
}


Well, it’s not.

Nice post! Great job.

good luck

hi, im sorry, the advanced tips were where?

Hi. We do not believe if we do not live and work according to our belief.
I am from Jamaica and learning to read in English, tell me right I wrote the following sentence: “A wall clock with a visible pendulum and simple or complex striking train onto are some examples of wall clocks with pendulum movements – return to.”

Best regards :D, Kevin.

Some of your tips are just plain stupid to be honest you should not post any more articles untill u know what u are on about how dose posting bogus tips in your articles help upcoming or prolific designers

I suggest you read up on the topic of your post before you post

Have you even herd of google? how about insted of posting rubbish you do a little research

I am not saying that your article isnt helpful its just a bit misinformed and that really needs to change.

How about you go back and refine this post!

I think it’s stupid that this webpage is too long.
But the article is really good. Contact Me:hndxjz@163.com

To the article author: Check at the bottom of the link you gave for the 10th point:

Apparently the sarcasm of this blog is failing for many readers, so I added this disclaimer: IT IS SARCASM, USE STRLEN.

Too good…

and very nice tricks.. related to performance.. which generally people.. forget.. or dont consider it…

Thanks
Voizle

This is quite excellent and most of them i use. So many many thanks for the tips