Small! - Revision history

Unclebob at 17:12, 18 February 2009

2009-02-18T17:12:23Z

←Older revision		Revision as of 17:12, 18 February 2009
Line 46:		Line 46:
	"But doesn't the proliferation of functions make the code more confusing?"		"But doesn't the proliferation of functions make the code more confusing?"

-	It certainly does if the proliferated functions are scattered hither and yon with no sense of organization. However, when those small functions ~~are~~ ordered and organized then they aren't confusing at all. Large and deeply indented functions are much more confusing that a well organized set of simple little functions.	+	It certainly does if the proliferated functions are scattered hither and yon with no sense of organization. However, when those small functions gathered together into a well ordered and organized module, then they aren't confusing at all. Large and deeply indented functions are much more confusing that a well organized set of simple little functions.

	Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.		Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.

Unclebob at 13:45, 26 November 2008

2008-11-26T13:45:11Z

←Older revision		Revision as of 13:45, 26 November 2008
Line 46:		Line 46:
	"But doesn't the proliferation of functions make the code more confusing?"		"But doesn't the proliferation of functions make the code more confusing?"

-	It certainly does if the proliferated ~~function~~ are scattered hither and yon with no sense of organization. However, when those small functions are ordered and organized then they aren't confusing at all. Large and deeply indented functions are much more confusing that a well organized set of simple little functions.	+	It certainly does if the proliferated functions are scattered hither and yon with no sense of organization. However, when those small functions are ordered and organized then they aren't confusing at all. Large and deeply indented functions are much more confusing that a well organized set of simple little functions.

	Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.		Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.

Unclebob at 13:44, 26 November 2008

2008-11-26T13:44:00Z

←Older revision		Revision as of 13:44, 26 November 2008
Line 46:		Line 46:
	"But doesn't the proliferation of functions make the code more confusing?"		"But doesn't the proliferation of functions make the code more confusing?"

-	~~No, just~~ the ~~opposite~~. Large and deeply indented functions are much more confusing that ~~lots~~ of simple little functions.	+	It certainly does if the proliferated function are scattered hither and yon with no sense of organization. However, when those small functions are ordered and organized then they aren't confusing at all. Large and deeply indented functions are much more confusing that a well organized set of simple little functions.

	Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.		Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.

Unclebob at 23:30, 19 November 2008

2008-11-19T23:30:25Z

←Older revision		Revision as of 23:30, 19 November 2008
Line 22:		Line 22:
	}		}

-	Notice that it doesn't feel so much like work. You can look at it, and grasp the intent without much effort. Not much has changed, I've just cleaned up a ~~few variable names and extracted a few functions~~. And yet that small change, so easy to do with modern refactoring browsers and a suite of tests, makes the function much easier to read.	+	Notice that it doesn't feel so much like work. You can look at it, and grasp the intent without much effort. Not much has changed, I've just cleaned up the code a little. And yet that small change, so easy to do with modern refactoring browsers and a suite of tests, makes the function much easier to read.

	The extracted functions are pretty easy to read too:		The extracted functions are pretty easy to read too:
Line 53:		Line 53:

	Yes, it's generally better to have a place for everything and put everything in it's place. And that's just what dividing your code into many small functions is. Large functions are just like all the clothes under your bed. Splitting them up into many little functions is like putting all your clothes on hangers and sorting them nicely in your closet. Large functions are a child's way to organize. Small functions are an adult's (or should I say a professional's) way to organize.		Yes, it's generally better to have a place for everything and put everything in it's place. And that's just what dividing your code into many small functions is. Large functions are just like all the clothes under your bed. Splitting them up into many little functions is like putting all your clothes on hangers and sorting them nicely in your closet. Large functions are a child's way to organize. Small functions are an adult's (or should I say a professional's) way to organize.
-
-	Of course it's more than just keeping functions small and simple. You also need to keep their coupling low. You don't want them to know about too many variables or take too many arguments. The more variables and arguments the tighter the coupling. I generally prefer that a function have fewer than 3 arguments. Two is better. One if even better! And of course ZERO is best!
-
-	Classes should also be small. A few dozen methods, and perhaps half a dozen variables is a good upper bound.
-

	by [[Uncle Bob]]		by [[Uncle Bob]]

Unclebob at 13:02, 18 November 2008

2008-11-18T13:02:30Z

←Older revision		Revision as of 13:02, 18 November 2008
Line 41:		Line 41:

	The point is that functions should be ''small''. How small? Just a few lines of code with one or two levels of indent.		The point is that functions should be ''small''. How small? Just a few lines of code with one or two levels of indent.
		+
		+	"You can't be serious!" I hear you say. But serious I am. It is far better to have many small functions than a few large ones.
		+
		+	"But doesn't the proliferation of functions make the code more confusing?"
		+
		+	No, just the opposite. Large and deeply indented functions are much more confusing that lots of simple little functions.
		+
		+	Think of it this way. When you were young you had a "system" for knowing where all your things were. They were on the floor of your room, or under the bed, or in a pile in your closet. Your mother would yell at you from time to time to clean up your room, but you did your best to thwart her intent because your system worked just fine for you. You knew that tomorrow's socks were right on the floor where you left them last night. The same for your underwear. You knew that your favorite toy was under your bed somewhere. You had a system.
		+
		+	But finally your mother got so frustrated that she forced you to help her (meaning watch her) clean up your room. You watched as she hung clothes up in the closet, and put toys on shelves or in drawers. You watched as she organized your things and put them away. And (sometime in your 30s) you realized that she had a point.
		+
		+	Yes, it's generally better to have a place for everything and put everything in it's place. And that's just what dividing your code into many small functions is. Large functions are just like all the clothes under your bed. Splitting them up into many little functions is like putting all your clothes on hangers and sorting them nicely in your closet. Large functions are a child's way to organize. Small functions are an adult's (or should I say a professional's) way to organize.
		+
		+	Of course it's more than just keeping functions small and simple. You also need to keep their coupling low. You don't want them to know about too many variables or take too many arguments. The more variables and arguments the tighter the coupling. I generally prefer that a function have fewer than 3 arguments. Two is better. One if even better! And of course ZERO is best!
		+
		+	Classes should also be small. A few dozen methods, and perhaps half a dozen variables is a good upper bound.

Unclebob at 00:26, 17 November 2008

2008-11-17T00:26:51Z

←Older revision		Revision as of 00:26, 17 November 2008
Line 41:		Line 41:

	The point is that functions should be ''small''. How small? Just a few lines of code with one or two levels of indent.		The point is that functions should be ''small''. How small? Just a few lines of code with one or two levels of indent.
		+
		+
		+	by [[Uncle Bob]]
		+
		+	This work is licensed under a
		+	[http://creativecommons.org/licenses/by/3.0/us/ Creative Commons Attribution 3]
		+
		+
		+	Back to [[97 Things Every Programmer Should Know]] home page

Unclebob at 00:25, 17 November 2008

2008-11-17T00:25:42Z

←Older revision		Revision as of 00:25, 17 November 2008
Line 1:		Line 1:
-	Look at this code	+	Look at this code:
	private void executeTestPages() throws Exception {		private void executeTestPages() throws Exception {
	Map<String, LinkedList<WikiPage>> suiteMap = makeSuiteMap(page, root, getSuiteFilter());		Map<String, LinkedList<WikiPage>> suiteMap = makeSuiteMap(page, root, getSuiteFilter());
Line 11:		Line 11:
	}		}
	}		}
		+
		+	Your first reaction is probably not positive. Not because the code is that complicated or daunting, but just because you don't necessarily feel like untangling the intent hidden in 11 lines of code with 3 levels of indent. You know you can do it, but it feels like work.
		+
		+	Now look at this function:
		+	private void executeTestPages() throws Exception {
		+	Map<String, LinkedList<WikiPage>> pagesByTestSystem;
		+	pagesByTestSystem = makeMapOfPagesByTestSystem(page, root, getSuiteFilter());
		+	for (String testSystemName : pagesByTestSystem.keySet())
		+	executePagesInTestSystem(testSystemName, pagesByTestSystem);
		+	}
		+
		+	Notice that it doesn't feel so much like work. You can look at it, and grasp the intent without much effort. Not much has changed, I've just cleaned up a few variable names and extracted a few functions. And yet that small change, so easy to do with modern refactoring browsers and a suite of tests, makes the function much easier to read.
		+
		+	The extracted functions are pretty easy to read too:
		+
		+	private void executePagesInTestSystem(String testSystemName,
		+	Map<String, LinkedList<WikiPage>> pagesByTestSystem) throws Exception {
		+	List<WikiPage> pagesInTestSystem = pagesByTestSystem.get(testSystemName);
		+	announceTestSystem(testSystemName);
		+	startTestSystemAndExecutePages(testSystemName, pagesInTestSystem);
		+	}
		+
		+	private void announceTestSystem(String testSystemName) throws Exception {
		+	if (response.isHtmlFormat()) {
		+	suiteFormatter.announceTestSystem(testSystemName);
		+	addToResponse(suiteFormatter.getTestSystemHeader(testSystemName));
		+	}
		+	}
		+
		+	The point is that functions should be ''small''. How small? Just a few lines of code with one or two levels of indent.

Unclebob at 00:05, 17 November 2008

2008-11-17T00:05:24Z

←Older revision		Revision as of 00:05, 17 November 2008
Line 1:		Line 1:
-	Look at this code ~~<tt>~~	+	Look at this code
	private void executeTestPages() throws Exception {		private void executeTestPages() throws Exception {
	Map<String, LinkedList<WikiPage>> suiteMap = makeSuiteMap(page, root, getSuiteFilter());		Map<String, LinkedList<WikiPage>> suiteMap = makeSuiteMap(page, root, getSuiteFilter());
Line 10:		Line 10:
	startTestSystemAndExecutePages(testSystemName, pagesInTestSystem);		startTestSystemAndExecutePages(testSystemName, pagesInTestSystem);
	}		}
-	}~~</tt>~~	+	}

Unclebob: New page: Look at this code `private void executeTestPages() throws Exception { Map> suiteMap = makeSuiteMap(page, root, getSuiteFilter()); for (String tes...`

2008-11-17T00:04:59Z New page: Look at this code <tt> private void executeTestPages() throws Exception { Map<String, LinkedList<WikiPage>> suiteMap = makeSuiteMap(page, root, getSuiteFilter()); for (String tes... New page Look at this code <tt> private void executeTestPages() throws Exception { Map<String, LinkedList<WikiPage>> suiteMap = makeSuiteMap(page, root, getSuiteFilter()); for (String testSystemName : suiteMap.keySet()) { if (response.isHtmlFormat()) { suiteFormatter.announceTestSystem(testSystemName); addToResponse(suiteFormatter.getTestSystemHeader(testSystemName)); } List<WikiPage> pagesInTestSystem = suiteMap.get(testSystemName); startTestSystemAndExecutePages(testSystemName, pagesInTestSystem); } }</tt>