Do not unnecessary load session or other scopes

Scenario:

settings file:
database_conn = instantiate.object
session_scope.conn_obj = database_conn or
application_scope.conn_obj = database_conn or others

script file:
object.init(application_scope.conn_obj)

You should not do that. It’s easy, indeed, because you can forget now about where and how is defined the object and you always have it handy in your application/session/other scope. BUT you will load your scope with unnecessary data and it’s a bad practice.

Instead, you should give the objects/variables as arguments wherever you need (in a good MVC framework you need to do things only once as in the module controller or settings file).

object.init(database_conn)

Programming frameworks – MVC

If you have no ideea what MVC (Model-View-Controller) is about please read here, here, here and/or here.

When you start-up as a programmer, no matter what language, you first learn iterative programming, then your teacher learns about recursive programming and he shows to you and you are both happy, then you hurry up to do spaghetti programming for tens of projects, then your five years younger neighbour tells you about structured programming and you start to spend weeks on adjusting your projects code, and later you read about OOP in a cookbook and you delete all your projects to start new ones

From the beginning of his career the programmer tries to design and improve nice and efficient frameworks. Depending on the programming language the frameworks have different characteristics, of course, therefore you can’t use the exactly same framework characteristics.

But, as general programming behavior, I’d like to propose some guidelines regarding frameworks:

• Try as much as possible to build/choose MVC frameworks from the beginning for your applications
• Though we don’t like too much theory learning, read and learn about the MVC notions and specialists’ articles in order to improve your architecture logic; you may be surprised to find out that most of the time your application may run faster or be easier to maintain if you do the right customization, even if it’s related to one module of your application only
• If it’s working and it suits your projects, your team is using it and you’ve already built the documentation, stick to it. Don’t try to change the projects’ frameworks on the fly, especially when you have a team using it. It takes lot of time and many issues keeps popping up, trust me. You should only change the framework if it’s bad from the beginning and it can’t be improved.
• Try to choose/buy from the beginning a good framework that suits your needs. There are so many frameworks for almost all programming languages that it’s almost impossible not to find a suitable one. Learn the choosed one, they usually come with good manuals, and adjust it as you wish. It always takes less time and money. Just remember, if you have very complex projects that need too much out-of-the-box-framework customization for power and speed improvement (web big projects usually do), you might be considering as well to start you framework from scratch.

MVC frameworks examples: CakePHP (php), FuseBox (coldfusion, php), Struts (java), Spring (java) and many others (just google).

Internet slang should have DYC!

Document Your Code! Document Your Code! Document Your Code!

Internet slang should accept the DYC (or DYFC if you’re very angry) acronym. I’m going nut when I have to take over or to debug someone’s else UNCOMMENTED or poor commented code. I will write a tutorial on how one should comment and document his/her applications’ code.

So, please DYC!