Rules of the code

[Q695]

Could you put a list of rules of coding together on different topics, like quotes, and other things?

[trq]

Could you put a list of rules of coding together on different topics, like quotes, and other things?

 

You mean like a basic php tutorial?

[Daniel0]

You want a tutorial on best practices? That's going to be difficult. That topic is highly subjective.

[Q695]

Rules on things to look at when debugging different things, and what to check when working on different things.

[.josh]

We have a debugging tutorial.  Why don't you go to the main site and look at what tutorials are there...

[burnside]

We have a debugging tutorial.  Why don't you go to the main site and look at what tutorials are there...

 

because that would be too easy . . . .

[revraz]

Am I the only one that chuckled at this?

 

Rules on things to look at when debugging different things, and what to check when working on different things.

[Q695]

I was serious about tiny manuals like if then else if else applications (like an outline that allows you to more easily debug your own applications)

[premiso]

I was serious about tiny manuals like if then else if else applications (like an outline that allows you to more easily debug your own applications)

 

Debugging is really a guess and check system. There can be certain systematic approaches that help you solve the problem easier, like common sense. Probably at least 80% of the time the problem ends up being something so simple and so small, any type of debugging system out there would have passed it up and you only caught it because you were tired of trying stuff and decided to just look at the code printed on paper.

 

There are certain tactics you can use to debug, such as printing variables, removing certain items from an equation etc. But in the end it all depends on the person and their knowledge/way of thinking. As for me, anytime I have a problem I tend to jump into the common items too fast instead of just stepping back and looking at the code as a whole. Printing it on paper and looking at it that way will generally solve any issues of bad variable names or easily mistaken items like that. If I do not see anything wrong with the code, I move forward and start to test my variable input (if there is any) and making sure the right data is being passed through etc.

 

And I never start to debug on the original copy, I make a backup, or at least a backup of the original (if not using SVN) and go from there. Cause you could find the error in a different file, or it was soo minor you can easily go change the original and not have to remove all your debugging junk.

 

But that is just my methodology and it seems to work pretty well for me. The more you know and the more you code the easier debugging is going to be. Just do not be so quick to jump on the bandwagon as "help me with this error" on forums. Take the time and work through the problem with a system in tact, do the research of the problem if necessary and see if it is a common problem that can easily be solved. 80% of the time you can do it just by making the effort the other 20% chances are it is lack of knowledge and asking for help may lead you down the right path.

 

What you want, these "rules" are not very viable. Depending on where/who you code for they may have their own rules, such as variable naming and commenting on code you create. The naming schemes I love. It keeps you thinking on what the variable should contain and keeps your names consistent. But for a "generic" rule, no. There are so many different ways 1 item can be coded and re-coded and they all work. Just not viable.

 

That is just my 2cents.

[Daniel0]

You could also use a real debugger instead of ad hoc changes to the code that you might forget to revert.