Totally Agree to you, its just that, i am wanting to really really build a base, and as we go on if you look at my Noob Index, by the time we complete the NOOB CMS, i should be able to implement all best practices by the help of people like you to help me through.
Kind of makes sense, I guess... But, I never get why teach bad practice first for sake of some "simplicity" and then teach the better one on a later stage. Especially when both bad and good ways of doing stuff are identical - e.g. in this particular case it's == vs ===. These are exactly the same for a newbie, so just pick === from the very beginning with a short note saying why it's better than ==. Building up from simpler to more complex stuff makes sense for teaching broader topics and concepts - OOP, dependency injection, autoloading etc. For basic stuff, imho, it brings more confusion than necessary on later stages.
I have an idea, based on your conclusion, Once we complete the bad version, I will add a section to it, Unit Testing or perhaps Refracting the Code. That is where I with your help and other helpers can really create a basis of how anyone else code or perhaps a piece of code can be tested before made production.
I like the idea :) Not sure 'Unit Testing' fits here (too complicated topic for newbies), but 'Refactoring the Code' sounds logical. A separate post going through all the code and explaining where, how and why it can be improved. I'd be happy to co-author that post with you.
Totally Agree to you, its just that, i am wanting to really really build a base, and as we go on if you look at my Noob Index, by the time we complete the NOOB CMS, i should be able to implement all best practices by the help of people like you to help me through.
Kind of makes sense, I guess... But, I never get why teach bad practice first for sake of some "simplicity" and then teach the better one on a later stage. Especially when both bad and good ways of doing stuff are identical - e.g. in this particular case it's == vs ===. These are exactly the same for a newbie, so just pick === from the very beginning with a short note saying why it's better than ==. Building up from simpler to more complex stuff makes sense for teaching broader topics and concepts - OOP, dependency injection, autoloading etc. For basic stuff, imho, it brings more confusion than necessary on later stages.
I have an idea, based on your conclusion, Once we complete the bad version, I will add a section to it, Unit Testing or perhaps Refracting the Code. That is where I with your help and other helpers can really create a basis of how anyone else code or perhaps a piece of code can be tested before made production.
I like the idea :) Not sure 'Unit Testing' fits here (too complicated topic for newbies), but 'Refactoring the Code' sounds logical. A separate post going through all the code and explaining where, how and why it can be improved. I'd be happy to co-author that post with you.
I have added you on the Noob Index