programmer Comparison Table

programmer

Next kbTop: programming Up: kbTop Previous kbTop: process

programmer comparison table

Subject follow comment consider choose reject be is a kind of is a subtopic of group avoid create remember restructure apply check for use ensure pay attention to keep write learn about take advantage of adhere to

kbTop

programmer the specific conventions for commenting classes and methods that allow for documentation to be automatically generated using a program called 'javadoc' whatever is non-obvious but should not comment obvious things as this adds clutter languages other than Java for number-crunching applications alternative that makes code simpler over more complicated one 'clever' or 'cool' coding techniques unless they make the code simpler to understand responsible for anticipating things that can go wrong and writing exception handling code in preparation kbTop Programming classes into logical sections with a clear comment separating each section if a class has many methods over-use of class variables or class methods several small classes, rather than one big, complex class that shorter code is not necessarily better code but unnecessarily long code is also bad code to make it simpler if necessary the 'isa' rule religiously valid generalizations by checking that:
superclasses and subclasses have unambiguous names
each subclasses retains its distinctiveness throughout its life
all the inherited features must make sense in each subclass
consistent code layout style that anything that is true in a superclass is also true in its subclasses to the documentation describing which features of Java are deprecated the number of instance variables small. If this number exceeds 10, then consider splitting the class into separate classes - e.g. a superclass and a subclass comments at the same time as writing code , and perhaps even before writing the code about the different programming strategies that make a Java program run faster polymorphism, inheritance, abstract classes, and methods object oriented principles

Next kbTop: programming Up: kbTop Previous kbTop: process

Subject	follow	comment	consider	choose	reject	be	is a kind of	is a subtopic of	group	avoid	create	remember	restructure	apply	check for	use	ensure	pay attention to	keep	write	learn about	take advantage of	adhere to
kbTop
programmer	the specific conventions for commenting classes and methods that allow for documentation to be automatically generated using a program called 'javadoc'	whatever is non-obvious but should not comment obvious things as this adds clutter	languages other than Java for number-crunching applications	alternative that makes code simpler over more complicated one	'clever' or 'cool' coding techniques unless they make the code simpler to understand	responsible for anticipating things that can go wrong and writing exception handling code in preparation	kbTop	Programming	classes into logical sections with a clear comment separating each section if a class has many methods	over-use of class variables or class methods	several small classes, rather than one big, complex class	that shorter code is not necessarily better code but unnecessarily long code is also bad	code to make it simpler if necessary	the 'isa' rule religiously	valid generalizations by checking that: superclasses and subclasses have unambiguous names each subclasses retains its distinctiveness throughout its life all the inherited features must make sense in each subclass	consistent code layout style	that anything that is true in a superclass is also true in its subclasses	to the documentation describing which features of Java are deprecated	the number of instance variables small. If this number exceeds 10, then consider splitting the class into separate classes - e.g. a superclass and a subclass	comments at the same time as writing code , and perhaps even before writing the code	about the different programming strategies that make a Java program run faster	polymorphism, inheritance, abstract classes, and methods	object oriented principles