Watching the videos, they are amzing. Difference between class and a datastructure Boundries in software projects ( Should applications know database schema) – How should we manage applications and other divisions of databases Are you ready : Burecratic urge to create a document called coding standards. Every team should have one and every developer should follow. • The code should be coding standard. • Comments should be rare – when you make programmers to comment on the code, then do it as practice. The boy who cried for wolf. o Should be in red, if used and should be rare because it is important and programmers cannot understand with out reading o Best documentation is clean structures, light comments, program description is optional. The code should self readable as a prose. o Reading code, the programmer should understand what program will do o If you feel that the comment should be there for every 2 lines of code, then it’s a failure o Some languages in assembly language, you need comments o Resource constraints dominents the structure of the code, due to pressure o In java, there are powerful things to express intent o Processors are fast, memory is high and you need to express the code o Every comment is a failure for the code failure o Every comment - I cannot we figure out that I cannot write the expressable code, so I write comments o Comments tends to be clutter and lies, when the code goes for a long time in the process then the comments will get changed o Programmers cannot keep the comments up to date, comments tend to be wroght because they are non local. If you fix a code, then how you think that is not reflected. The comments gradually becomes lie and do more harm than good o Legal information comment, informative syntax, - good o Clarification and explanation of intent o TODO comment – not used Bad comments Redundant explations, don’t tell the algorithm if its clearly visibly o DRY – Don’t repeat yourself. o Code styles should be checked off o Comments should be deleted or replaced. Don’t have misleading comments o Source code management system o Big banner comments, should be avoided o Closing brace comments – don’t use them o Source code control system will make changes and know what code you have written o Don’t put html in the code o Comments, where functions are changed, variables have got changed o I simply delete the code, and expunge from the system o Nice explaratory functions and meanings o Professional code and formatting, it’s a business for communication. Communication of code is importand then work o Code should not spill off the screen o Line legth , don’t use more than 80 to 100 character width in a line o Choose a style and then code it, don’t code and apply style o Don’t reformat the whole file o Base class should be proper o Car – get PercentFuelRemaining() • Polymorphishm for plugin structure,
