I'm about to become a PHP developer (not certain yet). Any advices?

Yeah, don't.

To elaborate on that advice.

PHP is a pretty messy language making it difficult to use correctly, Even if you personally manage to master it you will end up working with people who don't understand the many pitfalls the language has which will eventually drive you insane or cause you to do something horribly illegal to your coworkers.

Working with pretty much any other language greatly reduces the risk that you'll end up in a mental institution or prison.

@ItsNotMyFault Nearly everything you said is stupid.

Php has standards like any other language, since 7.x it is 2x as fast and while not perfect (which no language is) is more than capable as a server side language.

Google + "php best practices"

@nblackburn PHP has standards yes, but that doesn't help much when the language core is fubar as the standards mostly cover superficial things.

Even a "simple" thing like splitting a variable containing a string into an array of characters is obnoxiously difficult to get right in that piece of shit language. (If you can provide a correct example of how to do that in here without looking at the documentation i'll be impressed because 99% of all php devs do it incorrectly on their first try)

@DLMousey

That will give the wrong result on most strings, thanks for proving my point though :)

(I work with PHP btw, I spend way too much time fixing those mistakes)

@DLMousey str_split splits into an array of bytes. Not characters. It will mangle Unicode. (Reading the documentation helps there)

Dont stick to any programming language. Learn the basic, principle, design behind the programming language itself. The language is just a the instrument and you are the artist. Be a good obe no matter what language is. Have fun!!

@DLMousey it is 2017 not 1987.

Unicode is everywhere. Clients expect it to work without knowing what it is.

Assuming ASCII as a developer is never a good idea.

For actual advice, avoid the urge to put complicated logic inside the html. Generate all your values first, then render the html. Separating the data from its presentation makes later changes easier.

Also, have some system of distinguishing files representing endpoints from included files. I am going through a project converting a PHP site to Go, and figuring out what endpoints existed was extremely difficult. Most of the time, included PHP sources were outside the webroot directory and in inc/, but not always, and that bit us badly when trying to build the sitemap.

Inside the display logic, if statements should not use && or ||, especially if the condition takes up more than one visual line. Build a boolean variable before the display logic, and name it after the feature you are enabling or disabling.

@ItsNotMyFault It's your job to make it support what your clients throw at it, not the languages.

I am against things happening magically, it is also not a good idea.

The language provides the toolset to accommodate that.

PHP is useful for startups and new projects, because it has a shallow learning curve and doesn't need a lot of external libraries to do basic things. It lets you figure things out quickly, if you are starting from scratch.

The problem is when you are not starting from scratch and have to read someone else's code. PHP imposes very few rules on structure, and this often results in no structure, unless you impose it upon yourself.

After a startup is successful for a few years, switching the site to a more opinionated language will clear up a lot of the structural mess going forward. Plus, you get to throw out stale code and weird quirks from when you were just figuring things out.

Begun, the framework wars have!

Try to use frameworks (good ones) it helps a lot .

@nblackburn The real world doesn't quite work that way. In the real world you will work with other people and if you don't suck too much it will be your job to clean up their mess, The mess created by even fairly "senior" PHP developers is staggering and pretty much all of it is caused by them not really knowing the language and i really can't blame them, It is easier to write correct code for the web using C++ than it is to do it using PHP these days (And C++ is a pretty horrible mess of a language as well)

@IbrahimAbdo but on the other hand,0 !== "any string"

@ItsNotMyFault Don't be condescending, no need for it.

Correct is subjective and who in the right mind would write c for the web.

If you know what you are doing, PHP is a very capable choice, because of it's accessibility most people don't.

Truth is you don't like it and that is fine, but there is no reason to talk down to people or shit all over it when you clearly don't understand it enough to be aware of it's flaws.

@nblackburn the main part I'm liking php for is its type safety and at the same time its lack of type safety.

@McSebi so nothing then...

Guys please BRBN

If you are using frameworks like laravel PHP is awesome

@ItsNotMyFault I believe preg_split('//i', $str) does the trick.

@hendrik nice. it should be //u though but yes, preg_split is probably the best way to do it.

(The only other way to get a correct result that i can think of would be using mb_strlen and mb_substr but that performs worse and isn't pretty).

@nblackburn capability is irrelevant, C is capable, that doesn't make it a great choice (Although for a modern microservice architecture it can be a good one and it is gaining in popularity), PHP is to put it bluntly, a bad choice. The language is a mess, developers who know the language well enough don't want to work with it, It has no redeeming qualities. (I've used it for 17 years and can't think of a single thing that is actually positive about it)

@ItsNotMyFault I am having a hard time believing you used it for 12 years and yet not find anything good to say about it or give a valid reason to why it is so bad (stating it is bad with nothing to back it doesn't count).

I think you are just being salty like you have been with other languages.

In a side-note, preg_split is slow on larger strings, look into the mb_ functions for working with multi-byte strings.