First off, I, and many others within the Monestary will agree that there are times when (nearly) all the "best practices" will be broken for good reasons. It has even been stated that some of the "best practices" possibly aren't good for some people/groups at all.
So, yes, they are best to be looked upon as guidelines, not laws. (And, the title of the book specifically says these are not to be looked upon as laws) Having said that, those who have extensive experience coding in their language of choice are attempting to communicate a set of "best practices" such that those who are not as far along the path as they are, might be able to avoid some of the pain they've experienced along that path. Ignoring them is probably not in your best interest. So, if you are uninitiated, and your point of view is often one expressed by those who've not been on the path very long, you will be better off in the long run if you choose to listen and incorporate as many of the "best practices" as you are able. It will also probably be helpful if you continue to attempt to incorporate these practices as you evolve. As you do this, there will be some practices that you just don't agree with; don't lose any sleep over them, as you said, they are only guidelines. -Scott | [reply] |
One of the things that you learn as an art major is that all rules are meant to be broken when 'needs must'. The hard part is to know just when that is.
--hsm
"Never try to teach a pig to sing...it wastes your time and it annoys the pig."
| [reply] |
If you have enough knowledge and experience to be able to convince others who are equally or more knowledgable and experienced, of the need to turn against certain guidelines in a particular instance, that is when it becomes likely you are right to turn against those guidelines for that particular instance.
-Scott
| [reply] |
