Structure over Function - Revision history

Kevlin at 12:17, 17 August 2009

2009-08-17T12:17:00Z

←Older revision		Revision as of 12:17, 17 August 2009
Line 1:		Line 1:
-	When learning to program, the function of a piece of code is the most important thing to get right~~, once you have mastered the syntax of the programming language~~. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that ~~first~~ satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.	+	When learning to program, once you have mastered the syntax of the programming language, the function of a piece of code is the most important thing to get right. It feels great to pass the hurdle of getting a program to actually ''run'' and do what you intended. Unfortunately, that initial satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.

	So what is missing?		So what is missing?

-	You or others will have to read, understand, use and modify your program code. ~~Evolution and change of~~ code is inevitable. ~~Thus, you~~ need to ensure that your code can evolve while its functionality survives.	+	You and others will have to read, understand, use, and modify your program code. Changes to code are inevitable. You therefore need to ensure that your code can evolve while its functionality survives.

-	One of the most ~~dominant~~ barriers to evolution is the code's structure.	+	One of the most significant barriers to evolution is the code's structure. Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems — its overall design and architecture.
-	Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its design and architecture.	+

-	~~Bad structure hindering~~ change comes in many different species. ~~An easy~~ taxonomy of code structure ~~are~~ the Single Responsibility Principle ~~(high cohesion~~) and low coupling. Both are easy to measure and understand ~~but~~ very hard to achieve. Violation of these principles is contagious, so without an antidote, code ~~using badly~~ structured code tends to ~~get~~ degenerate ~~structure~~ as well. Take low cohesion and high coupling or metrics showing structural disorder as symptoms to be remedied.	+	Hindrance to change from poor structure comes in many different species. The simplest taxonomy of code structure is in terms of high cohesion (i.e., the Single Responsibility Principle) and low coupling. Both are easy to measure and understand, and yet very hard to achieve. Violation of these principles is contagious, so without an antidote, code that depends on other, poorly structured code tends to degenerate as well. Take low cohesion and high coupling, or other metrics showing structural disorder, as symptoms to be diagnosed and remedied.

-	Refactoring is the treatment to improve code structure. ~~Test~~ automation and version control provide safety, so that treatment does no harm or can be easily undone.	+	Refactoring is the treatment to improve code structure. Automated refactoring, test automation, and version control provide safety, so that treatment does no harm or can be easily undone.

-	While the need to refactor is almost inevitable, because we learn about better solutions while we program, there are also preventive measures ~~in addition to~~ make refactoring less expensive and burdensome.	+	While the need to refactor is almost inevitable — because we learn about better solutions while we program — there are also preventive measures that make refactoring less expensive and burdensome.

-	~~Bad~~ structure can occur at all levels, good structure ~~starts~~ from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it. ~~Initially a~~ user might not recognize bad structure, as long as functionality is available, ~~but~~ evolving the system might not happen at a pace the user ~~desired,~~ once structural decay ~~happens~~ in ~~its~~ code.	+	Where poor structure can occur at all levels, good structure builds from the ground up. Keep your program code clean and understandable from the statement level to the coarsest partitioning. Consider your code as ''not'' "working" unless it is actually working in a way that you and other programmers can easily understand and evolve. A user might not initially recognize bad structure, so long as functionality is available. However, evolving the system might not happen at the pace the user expects or desires once structural decay in the code sets in.

-	Keep your code well organized. Program deliberately. Refactor mercilessly towards DRY code. Use ~~Patterns~~ and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture towards doing more with less code. Avoid too much up-front genericity and refactor away from laborious specific solutions repeating code.	+	Keep your code well organized. Program deliberately. Refactor mercilessly towards DRY code. Use patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture towards doing more with less code. Avoid too much up-front genericity and refactor away from laborious specific solutions repeating code.

-	As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system ~~grows~~ beyond "~~hello world~~"~~'s size.~~	+	As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system is to grow beyond the scale of "Hello, World!"

	by [[Peter Sommerlad]]		by [[Peter Sommerlad]]

PeterSommerlad: try rephrasing, do not know if metaphors work?

2009-08-14T08:46:24Z

try rephrasing, do not know if metaphors work?

←Older revision		Revision as of 08:46, 14 August 2009
Line 1:		Line 1:
-	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.	+	When learning to program, the function of a piece of code is the most important thing to get right, once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.

	So what is missing?		So what is missing?
Line 6:		Line 6:

	One of the most dominant barriers to evolution is the code's structure.		One of the most dominant barriers to evolution is the code's structure.
-	Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its architecture.	+	Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its design and architecture.

-	Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote code using badly structured code tends to get degenerate structure as well. Take ~~the Refactoring medicine~~ to ~~improve code structure~~.	+	Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote, code using badly structured code tends to get degenerate structure as well. Take low cohesion and high coupling or metrics showing structural disorder as symptoms to be remedied.

-	~~While bad~~ structure ~~can occur at all levels, good structure starts from the ground up~~. ~~Keep your program code clean~~ and ~~understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way~~ that ~~you and other programmers~~ can easily ~~understand and evolve it~~.	+	Refactoring is the treatment to improve code structure. Test automation and version control provide safety, so that treatment does no harm or can be easily undone.

-	Keep your code ~~well organized~~. ~~Take low cohesion~~ and ~~high coupling or metrics showing structural disorder~~ as ~~symptoms to be remedied~~. Refactor mercilessly ~~toward~~ DRY code. Use Patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture.	+	While the need to refactor is almost inevitable, because we learn about better solutions while we program, there are also preventive measures in addition to make refactoring less expensive and burdensome.
		+
		+	Bad structure can occur at all levels, good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it. Initially a user might not recognize bad structure, as long as functionality is available, but evolving the system might not happen at a pace the user desired, once structural decay happens in its code.
		+
		+	Keep your code well organized. Program deliberately. Refactor mercilessly towards DRY code. Use Patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture towards doing more with less code. Avoid too much up-front genericity and refactor away from laborious specific solutions repeating code.

	As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system grows beyond "hello world"'s size.		As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system grows beyond "hello world"'s size.

PeterSommerlad: an attempt to finish it

2009-08-12T13:54:50Z

an attempt to finish it

←Older revision		Revision as of 13:54, 12 August 2009
Line 5:		Line 5:
	You or others will have to read, understand, use and modify your program code. Evolution and change of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.		You or others will have to read, understand, use and modify your program code. Evolution and change of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.

-	~~Code needs~~ to ~~be clean to allow smooth~~ evolution~~. Cleanliness means good~~ structure. Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems.	+	One of the most dominant barriers to evolution is the code's structure.
		+	Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems: its architecture.

-	~~One of the most dominant barriers to evolution is the code's structure.~~ Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote code using badly structured code tends to get degenerate structure as well.	+	Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote code using badly structured code tends to get degenerate structure as well. Take the Refactoring medicine to improve code structure.

-	~~Bad~~ structure can occur at all levels, ~~but~~ good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it.	+	While bad structure can occur at all levels, good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it.

-	Keep your code well organized. Refactor mercilessly~~, if it needs improvement~~. Use Patterns to guide your efforts to improve the code's structure. Understand and evolve a system's architecture.	+	Keep your code well organized. Take low cohesion and high coupling or metrics showing structural disorder as symptoms to be remedied. Refactor mercilessly toward DRY code. Use Patterns and simplicity to guide your efforts to improve the code's structure. Understand and evolve a system's architecture.

-	~~and limit the number of elements or group them at~~ a ~~given level of abstraction as a guideline~~ to ~~judge~~ when ~~better structure is needed. Other principles apply as well. After the size~~, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your ~~code to keep its structure within understandable boundaries~~.	+	As a professional programmer you will know that function is important, but you need to focus on structural improvement when programming, if your system grows beyond "hello world"'s size.

	by [[Peter Sommerlad]]		by [[Peter Sommerlad]]

PeterSommerlad at 13:33, 12 August 2009

2009-08-12T13:33:30Z

←Older revision		Revision as of 13:33, 12 August 2009
Line 1:		Line 1:
-	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. It feels great pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.	+	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. It feels great to pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.

	So what is missing?		So what is missing?

-	You or others will have to read, understand, use and modify your program code. Evolution of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.	+	You or others will have to read, understand, use and modify your program code. Evolution and change of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.

		+	Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in a function, loop and conditional blocks; the nesting within control structures; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between classes, modules and subsystems.

-	~~Code needs to be clean~~ to ~~allow smooth~~ evolution~~. Cleanliness means good~~ structure. ~~Significant~~ structure ~~exists at~~ many ~~levels:~~ the ~~number~~ and ~~order of statements in loop~~ and ~~conditional blocks; the nesting within control structures; the statements within a function; the functions within a module or class; the relationships between one piece~~ of code ~~and others; the partitioning and dependencies between subsystems~~.	+	One of the most dominant barriers to evolution is the code's structure. Bad structure hindering change comes in many different species. An easy taxonomy of code structure are the Single Responsibility Principle (high cohesion) and low coupling. Both are easy to measure and understand but very hard to achieve. Violation of these principles is contagious, so without an antidote code using badly structured code tends to get degenerate structure as well.

-	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand.	+	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand and evolve it.

-	~~There are limits to our cognitive capacity depending on our state of mind~~. ~~If you concentrate very hard~~, ~~you might be able to grasp more individual elements at once~~. ~~However, usually our brain starts~~ to ~~group elements implicitly~~ to ~~keep some coherent picture of~~ the ~~whole~~. ~~Or, just fails to see the wood from the trees~~.	+	Keep your code well organized. Refactor mercilessly, if it needs improvement. Use Patterns to guide your efforts to improve the code's structure. Understand and evolve a system's architecture.

-	~~Try to keep your code organized~~ and limit the number of elements or group them at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.	+	and limit the number of elements or group them at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.

	by [[Peter Sommerlad]]		by [[Peter Sommerlad]]

PeterSommerlad at 13:04, 12 August 2009

2009-08-12T13:04:53Z

←Older revision		Revision as of 13:04, 12 August 2009
Line 1:		Line 1:
-	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. ~~Many programmers are easily satisfied~~ with ~~code~~ that (~~somehow~~) ~~works~~. ~~Please~~, ~~don't stop there~~. ~~This early satisfaction with function~~ can ~~be counterproductive~~.	+	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. It feels great pass the hurdle of getting a program to actually "run" and do what you intended. Unfortunately, that first satisfaction with your programming skills can be misleading. Programs that (seem to) work are necessary but not sufficient for your life as a good programmer.
		+
		+	So what is missing?
		+
		+	You or others will have to read, understand, use and modify your program code. Evolution of code is inevitable. Thus, you need to ensure that your code can evolve while its functionality survives.
		+

	Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in loop and conditional blocks; the nesting within control structures; the statements within a function; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between subsystems.		Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in loop and conditional blocks; the nesting within control structures; the statements within a function; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between subsystems.

PeterSommerlad at 12:37, 27 March 2009

2009-03-27T12:37:18Z

←Older revision		Revision as of 12:37, 27 March 2009
Line 1:		Line 1:
-	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. Many ~~non-professionals~~ are easily satisfied with code that (somehow) works. ~~But~~ don't stop there. This early satisfaction with function can be counterproductive.	+	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. Many programmers are easily satisfied with code that (somehow) works. Please, don't stop there. This early satisfaction with function can be counterproductive.

-	Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in loop and conditional blocks; the nesting within control structures; the statements within a function; the functions within a module or class; the ~~relationship~~ between one piece of code and ~~another~~; the partitioning and dependencies between subsystems.	+	Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in loop and conditional blocks; the nesting within control structures; the statements within a function; the functions within a module or class; the relationships between one piece of code and others; the partitioning and dependencies between subsystems.

-	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other ~~professionals~~ can easily understand.	+	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other programmers can easily understand.

-	There ~~is a well-known~~ cognitive capacity ~~for short-term memory: seven plus or minus two items, meaning that it is easy to grasp between five to nine different things at once but not more~~. If you ~~need~~ to ~~comprehend~~ more ~~things~~ at once~~, you either need to concentrate very hard or~~, usually~~, your~~ brain starts to group elements implicitly to keep some coherent picture of the whole.	+	There are limits to our cognitive capacity depending on our state of mind. If you concentrate very hard, you might be able to grasp more individual elements at once. However, usually our brain starts to group elements implicitly to keep some coherent picture of the whole. Or, just fails to see the wood from the trees.

-	Try to keep your code organized and ~~use this five-to-nine~~ elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.	+	Try to keep your code organized and limit the number of elements or group them at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.

	by [[Peter Sommerlad]]		by [[Peter Sommerlad]]

Kevlin at 11:44, 4 February 2009

2009-02-04T11:44:43Z

←Older revision		Revision as of 11:44, 4 February 2009
Line 1:		Line 1:
-	When learning to program, the function of a piece of code is the most important thing to get right ~~after~~ the syntax of the programming language ~~is mastered~~. Many non-professionals are easily satisfied with code that (somehow) works. ~~Do not~~ stop there.	+	When learning to program, the function of a piece of code is the most important thing to get right once you have mastered the syntax of the programming language. Many non-professionals are easily satisfied with code that (somehow) works. But don't stop there. This early satisfaction with function can be counterproductive.

-	~~This early satisfaction with function can be bad.~~ Code needs to be clean to allow smooth evolution. Cleanliness means good structure. ~~Good and bad~~ structure ~~exist~~ at many levels: the ~~amount~~ and order of statements in a loop or conditional; the nesting ~~of such~~ control structures; the statements within a function; the functions within a module or class; the relationship between one piece of code to another; the partitioning and dependencies between subsystems.	+	Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Significant structure exists at many levels: the number and order of statements in loop and conditional blocks; the nesting within control structures; the statements within a function; the functions within a module or class; the relationship between one piece of code and another; the partitioning and dependencies between subsystems.

	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other professionals can easily understand.		Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other professionals can easily understand.
Line 7:		Line 7:
	There is a well-known cognitive capacity for short-term memory: seven plus or minus two items, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to comprehend more things at once, you either need to concentrate very hard or, usually, your brain starts to group elements implicitly to keep some coherent picture of the whole.		There is a well-known cognitive capacity for short-term memory: seven plus or minus two items, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to comprehend more things at once, you either need to concentrate very hard or, usually, your brain starts to group elements implicitly to keep some coherent picture of the whole.

-	Try to keep your code organized and use this five-to-nine elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that ~~there are not only explicit but often also implicit~~ relationships. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.	+	Try to keep your code organized and use this five-to-nine elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that relationships can be implicit as well as explicit. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.

	by [[Peter Sommerlad]]		by [[Peter Sommerlad]]

Kevlin: Structure over function moved to Structure over Function

2009-02-04T11:32:34Z

Structure over function moved to Structure over Function

←Older revision

Revision as of 11:32, 4 February 2009

Kevlin at 16:09, 2 December 2008

2008-12-02T16:09:35Z

←Older revision		Revision as of 16:09, 2 December 2008
Line 1:		Line 1:
-	When learning ~~how~~ to program, the function of a piece of code is the most important thing to get right after the syntax of the programming language is mastered. Many non-professionals are easily satisfied with code that (somehow) works. Do not stop there.	+	When learning to program, the function of a piece of code is the most important thing to get right after the syntax of the programming language is mastered. Many non-professionals are easily satisfied with code that (somehow) works. Do not stop there.

-	This early satisfaction with function is bad. Code ~~must~~ be clean to ~~enable its~~ evolution. Cleanliness means good structure. Good or bad structure ~~comes~~ at many levels~~, from~~ the amount and order of statements in a loop or conditional~~, through~~ the nesting of such control structures~~, through~~ the statements within a function, the functions within a module or class, the ~~relationships of a~~ piece of code to ~~other pieces up to~~ the ~~architecture: the structure of~~ and dependencies between subsystems.	+	This early satisfaction with function can be bad. Code needs to be clean to allow smooth evolution. Cleanliness means good structure. Good and bad structure exist at many levels: the amount and order of statements in a loop or conditional; the nesting of such control structures; the statements within a function; the functions within a module or class; the relationship between one piece of code to another; the partitioning and dependencies between subsystems.

-	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level on. Consider your code is not "working" unless it is actually working in a way that you and other professionals can easily understand.	+	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level up. Consider your code as not "working" unless it is actually working in a way that you and other professionals can easily understand.

-	There is a well-known ~~psychological barrier of understanding that is often told as~~ seven plus/minus two, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to ~~handle~~ more things at once, you either need to concentrate very hard or usually your brain starts to group elements implicitly to keep ~~the~~ picture of the whole.	+	There is a well-known cognitive capacity for short-term memory: seven plus or minus two items, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to comprehend more things at once, you either need to concentrate very hard or, usually, your brain starts to group elements implicitly to keep some coherent picture of the whole.
-		+
-	Try to keep your code organized and use this five to nine elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. Next to the size the number of relationships should be minimized. Notice that there are not only explicit but often also implicit relationships. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.	+

		+	Try to keep your code organized and use this five-to-nine elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. After the size, the number of relationships should be minimized. Notice that there are not only explicit but often also implicit relationships. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.

	by [[Peter Sommerlad]]		by [[Peter Sommerlad]]

PeterSommerlad at 12:36, 2 December 2008

2008-12-02T12:36:27Z

←Older revision		Revision as of 12:36, 2 December 2008
Line 1:		Line 1:
	When learning how to program, the function of a piece of code is the most important thing to get right after the syntax of the programming language is mastered. Many non-professionals are easily satisfied with code that (somehow) works. Do not stop there.		When learning how to program, the function of a piece of code is the most important thing to get right after the syntax of the programming language is mastered. Many non-professionals are easily satisfied with code that (somehow) works. Do not stop there.

-	This early satisfaction with function is bad. Code must be clean to enable its evolution. Cleanliness ~~comes from~~ structure. Good or bad structure comes at many levels, from the amount and order of statements in a loop or conditional, through the nesting of such control structures, through the statements within a function, the functions within a module or class, the relationships of a piece of code to other pieces up to the architecture: the structure of and dependencies between subsystems.	+	This early satisfaction with function is bad. Code must be clean to enable its evolution. Cleanliness means good structure. Good or bad structure comes at many levels, from the amount and order of statements in a loop or conditional, through the nesting of such control structures, through the statements within a function, the functions within a module or class, the relationships of a piece of code to other pieces up to the architecture: the structure of and dependencies between subsystems.

-	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable. It is not "working" unless it is actually working in a way that you and other professionals can easily understand~~. The code must be so tidy and clean you can get it~~.	+	Bad structure can occur at all levels, but good structure starts from the ground up. Keep your program code clean and understandable from the statement level on. Consider your code is not "working" unless it is actually working in a way that you and other professionals can easily understand.

-	There is a well-known psychological barrier of understanding that is often told as seven plus/minus two, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to handle more things at once, you either need to concentrate very hard or usually your brain starts to group implicitly.	+	There is a well-known psychological barrier of understanding that is often told as seven plus/minus two, meaning that it is easy to grasp between five to nine different things at once but not more. If you need to handle more things at once, you either need to concentrate very hard or usually your brain starts to group elements implicitly to keep the picture of the whole.

-	Try to keep your code organized and use this five to nine elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. Next to the size the number of relationships should be minimized. Notice that there are not only explicit but often also implicit relationships. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction.	+	Try to keep your code organized and use this five to nine elements at a given level of abstraction as a guideline to judge when better structure is needed. Other principles apply as well. Next to the size the number of relationships should be minimized. Notice that there are not only explicit but often also implicit relationships. Understand and manage the number of relationships. Loosen coupling as much as it makes sense. On all levels of abstraction. Refactor your code to keep its structure within understandable boundaries.