Programming/Principles - Revision history

Admin at 22:27, 21 December 2021

2021-12-21T22:27:26Z

← Older revision		Revision as of 22:27, 21 December 2021
Line 467:		Line 467:
	* '''[M97]''' Bertrand Meyer. ''Object-Oriented Software Construction'', second edition. Prentice Hall, 1997.		* '''[M97]''' Bertrand Meyer. ''Object-Oriented Software Construction'', second edition. Prentice Hall, 1997.
	* '''[MPT78]''' M. D. McIlroy, E. N. Pinson, and B. A. Tague. UNIX Time-Sharing System: Foreword. ''The Bell System Technical Journal'', Vol. 57, No. 6, July–August 1978.		* '''[MPT78]''' M. D. McIlroy, E. N. Pinson, and B. A. Tague. UNIX Time-Sharing System: Foreword. ''The Bell System Technical Journal'', Vol. 57, No. 6, July–August 1978.
	* '''[P89]''' Rob Pike. ''Notes on Programming in C.'' February 21, 1989. ~~<span class="plainlinks">~~https://www.lysator.liu.se/c/pikestyle.html~~</span>~~		* '''[P89]''' Rob Pike. ''Notes on Programming in C.'' February 21, 1989. https://www.lysator.liu.se/c/pikestyle.html
	* '''[R03]''' Eric Steven Raymond. ''The Art of UNIX Programming.'' Pearson Education, 2003.		* '''[R03]''' Eric Steven Raymond. ''The Art of UNIX Programming.'' Pearson Education, 2003.
	* '''[S94]''' Peter H. Salus. ''A Quarter-Century of Unix.'' Addison–Wesley, 1994.		* '''[S94]''' Peter H. Salus. ''A Quarter-Century of Unix.'' Addison–Wesley, 1994.
	* '''[TH20]''' David Thomas, Andrew Hunt. ''The Pragmatic Programmer'', 20th Anniversary Edition. Addison–Wesley, 2020.		* '''[TH20]''' David Thomas, Andrew Hunt. ''The Pragmatic Programmer'', 20th Anniversary Edition. Addison–Wesley, 2020.
	* '''[Y79]''' Edward Yourdon, Larry L. Constantine. ''Structured Design: Fundamentals of a Discipline of Computer Program and System Design.'' Prentice–Hall, 1979.		* '''[Y79]''' Edward Yourdon, Larry L. Constantine. ''Structured Design: Fundamentals of a Discipline of Computer Program and System Design.'' Prentice–Hall, 1979.

Admin at 19:27, 19 July 2021

2021-07-19T19:27:59Z

@@ Line 1: / Line 1: @@
 =Principles=
 ==No Silver Bullet==
@@ Line 445: / Line 456: @@
 =Bibliography=
 * '''[B87]''' Fred Brooks. No Silver Bullet: Essence and Accidents of Software Engineering. ''IEEE Computer'', Vol. 20, No. 4, p. 12, 1987.
 * '''[BMECHY07]''' Grady Booch, Robert Maksimchuk, Michael Engle, Jim Conallen, Kelli Houston, Bobbi Young. ''Object-Oriented Analysis and Design with Applications''. Pearson Education, 2007.

Admin at 16:16, 17 July 2021

2021-07-17T16:16:03Z

← Older revision		Revision as of 16:16, 17 July 2021
Line 43:		Line 43:

	In contrast, you don't always need to make it fast. Benchmarks may show that your code's performance is already acceptable after the first two steps. When performance is not acceptable, profiling often shows that all performance issues are in a small part of the code, perhaps 10 to 20 percent of the code where your program spends 80 or 90 percent of the time. Such performance-crucial regions of your code are known as its ''bottlenecks'', or ''hot spots''. It's a waste of effort to optimize large portions of code that account for, say, 10 percent of your program's running time. Even if you made that part run 10 times as fast (a rare feat), your program's overall runtime would only decrease by 9 percent, a speedup no user would even notice. If optimization is needed, focus your efforts where they'll matter—on bottlenecks.		In contrast, you don't always need to make it fast. Benchmarks may show that your code's performance is already acceptable after the first two steps. When performance is not acceptable, profiling often shows that all performance issues are in a small part of the code, perhaps 10 to 20 percent of the code where your program spends 80 or 90 percent of the time. Such performance-crucial regions of your code are known as its ''bottlenecks'', or ''hot spots''. It's a waste of effort to optimize large portions of code that account for, say, 10 percent of your program's running time. Even if you made that part run 10 times as fast (a rare feat), your program's overall runtime would only decrease by 9 percent, a speedup no user would even notice. If optimization is needed, focus your efforts where they'll matter—on bottlenecks.
			</blockquote>

			==Don't Live with Broken Windows==

			From '''[TH20]''':

			<blockquote>
			In inner cities, some buildings are beautiful and clean, while others are rotting hulks. Why? Researchers in the field of crime and urban decay discovered a fascinating trigger mechanism, one that very quickly turns a clean, intact, inhabited building into a smashed and abandoned derelict.

			A broken window.

			One broken window, left unrepaired for any substantial length of time, instills in the inhabitants of the building a sense of abandonment—a sense that the powers that be don't care about the building. So another window gets broken. People start littering. Graffiti appears. Serious structural damage begins. In a relatively short span of time, the building becomes damaged beyond the owner's desire to fix it, and the sense of abandonment becomes reality.

			Why would that make a difference? Psychologists have done studies that show hopelessness can be contagious. Think of the flu virus in close quarters. Ignoring a clearly broken situation reinforces the ideas that perhaps ''nothing'' can be fixed, that no one cares, all is doomed; all negative thoughts which can spread among team members, creating a vicious spiral.

			Don't leave "broken windows" (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered. If there is insufficient time to fix it properly, then ''board it up''. Perhaps you can comment out the offending code, or display a "Not Implemented" message, or substitute dummy data instead. Take ''some'' action to prevent further damage and to show that you're on top of the situation.
	</blockquote>		</blockquote>

Admin at 11:06, 17 July 2021

2021-07-17T11:06:43Z

@@ Line 1: / Line 1: @@
 =Principles=
 ==First make it work. Then make it right. Then make it fast.==
@@ Line 212: / Line 245: @@
 "The flip side of the Rule of Least Surprise is to avoid making things superficially similar but really a little bit different. This is extremely treacherous because the seeming familiarity raises false expectations. It's often better to make things distinctly different than to make them ''almost'' the same."&mdash;Henry Spencer.
 </blockquote>
@@ Line 308: / Line 350: @@
 <blockquote>
 Modules should be both open and closed.
 </blockquote>
@@ Line 382: / Line 429: @@
 =Bibliography=
 * '''[BMECHY07]''' Grady Booch, Robert Maksimchuk, Michael Engle, Jim Conallen, Kelli Houston, Bobbi Young. ''Object-Oriented Analysis and Design with Applications''. Pearson Education, 2007.
 * '''[BP81]''' K. Britton and D. Parnas. ''A-7E Software Module Guide''. Naval Research Laboratory, 1981.
 * '''[H10]''' Kevin Henney. ''97 Things Every Programmer Should Know''. O'Reilly, 2010.
 * '''[J87]''' Geoffrey James. ''The Tao of Programming''. 1987.

Admin at 10:57, 17 July 2021

2021-07-17T10:57:16Z

← Older revision		Revision as of 10:57, 17 July 2021
Line 194:		Line 194:
	</blockquote>		</blockquote>

	==The Principle of Least Astonishment==		==The Principle of Least Astonishment (POLA)==

	The '''Principle of Least Astonishment (POLA)''' '''[J87, R03]''':		The '''Principle of Least Astonishment (POLA)''' '''[J87, R03]''':
	<blockquote>		<blockquote>
	A component of a system should behave in a way that most users will expect it to behave.		A component of a system should behave in a way that most users will expect it to behave.

Admin at 10:56, 17 July 2021

2021-07-17T10:56:47Z

← Older revision		Revision as of 10:56, 17 July 2021
Line 194:		Line 194:
	</blockquote>		</blockquote>

	==The ~~principle~~ of ~~least astonishment~~==		==The Principle of Least Astonishment==

	The '''Principle of Least Astonishment''' '''[J87, R03]''':		The '''Principle of Least Astonishment (POLA)''' '''[J87, R03]''':
	<blockquote>		<blockquote>
	A component of a system should behave in a way that most users will expect it to behave.		A component of a system should behave in a way that most users will expect it to behave.

Admin at 10:56, 17 July 2021

2021-07-17T10:56:11Z

← Older revision		Revision as of 10:56, 17 July 2021
Line 88:		Line 88:
	==The Unix philosophy==		==The Unix philosophy==

	From '''[~~R04~~]''':		From '''[R03]''':

	<blockquote>		<blockquote>
Line 192:		Line 192:

	Here's the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn't DRY.		Here's the acid test: when some single facet of the code has to change, do you find yourself making that change in multiple places, and in multiple different formats? Do you have to change code and documentation, or a database schema and a structure that holds it, or...? If so, your code isn't DRY.
			</blockquote>

			==The principle of least astonishment==

			The '''Principle of Least Astonishment''' '''[J87, R03]''':
			<blockquote>
			A component of a system should behave in a way that most users will expect it to behave.
			</blockquote>

			As explained in '''[R03]''':
			<blockquote>
			The easiest programs to use are those that demand the least new learning from the user—or, to put it another way, the easiest programs to use are those that most effectively connect to the user's pre-existing knowledge.

			Therefore, avoid gratuitous novelty and excessive cleverness in interface design. If you're writing a calculator program, "+" should always mean addition! When designing an interface, model it on the interfaces of functionally similar or analogous programs with which your users are likely to be familiar.

			Pay attention to your expected audience. They may be end users, they may be other programmers, or they may be system administrators. What is least surprising can differ among these groups.

			Pay attention to tradition. The Unix world has rather well-documented conventions among things like the format of configuration and run-control files, command-line switches, and the like. These traditions exist for a good reason: to tame the learning curve. Learn and use them.

			"The flip side of the Rule of Least Surprise is to avoid making things superficially similar but really a little bit different. This is extremely treacherous because the seeming familiarity raises false expectations. It's often better to make things distinctly different than to make them ''almost'' the same."—Henry Spencer.
	</blockquote>		</blockquote>

Line 365:		Line 385:
	* '''[BP81]''' K. Britton and D. Parnas. ''A-7E Software Module Guide''. Naval Research Laboratory, 1981.		* '''[BP81]''' K. Britton and D. Parnas. ''A-7E Software Module Guide''. Naval Research Laboratory, 1981.
	* '''[H10]''' Kevin Henney. ''97 Things Every Programmer Should Know''. O'Reilly, 2010.		* '''[H10]''' Kevin Henney. ''97 Things Every Programmer Should Know''. O'Reilly, 2010.
			* '''[J87]''' Geoffrey James. ''The Tao of Programming''. 1987.
	* '''[L87]''' Barbara Liskov. Data Abstraction and Hierarchy. OOPSLA, 1987.		* '''[L87]''' Barbara Liskov. Data Abstraction and Hierarchy. OOPSLA, 1987.
	* '''[M06]''' Alex Martelli. ''Python in a Nutshell'', second edition. O'Reilly, 2006.		* '''[M06]''' Alex Martelli. ''Python in a Nutshell'', second edition. O'Reilly, 2006.
Line 370:		Line 391:
	* '''[MPT78]''' M. D. McIlroy, E. N. Pinson, and B. A. Tague. UNIX Time-Sharing System: Foreword. ''The Bell System Technical Journal'', Vol. 57, No. 6, July–August 1978.		* '''[MPT78]''' M. D. McIlroy, E. N. Pinson, and B. A. Tague. UNIX Time-Sharing System: Foreword. ''The Bell System Technical Journal'', Vol. 57, No. 6, July–August 1978.
	* '''[P89]''' Rob Pike. ''Notes on Programming in C.'' February 21, 1989. <span class="plainlinks">https://www.lysator.liu.se/c/pikestyle.html</span>		* '''[P89]''' Rob Pike. ''Notes on Programming in C.'' February 21, 1989. <span class="plainlinks">https://www.lysator.liu.se/c/pikestyle.html</span>
	* '''[~~R04~~]''' Eric Steven Raymond. ''The Art of UNIX Programming.'' Pearson Education, ~~2004~~.		* '''[R03]''' Eric Steven Raymond. ''The Art of UNIX Programming.'' Pearson Education, 2003.
	* '''[S94]''' Peter H. Salus. ''A Quarter-Century of Unix.'' Addison–Wesley, 1994.		* '''[S94]''' Peter H. Salus. ''A Quarter-Century of Unix.'' Addison–Wesley, 1994.
	* '''[TH20]''' David Thomas, Andrew Hunt. ''The Pragmatic Programmer'', 20th Anniversary Edition. Addison–Wesley, 2020.		* '''[TH20]''' David Thomas, Andrew Hunt. ''The Pragmatic Programmer'', 20th Anniversary Edition. Addison–Wesley, 2020.
	* '''[Y79]''' Edward Yourdon, Larry L. Constantine. ''Structured Design: Fundamentals of a Discipline of Computer Program and System Design.'' Prentice–Hall, 1979.		* '''[Y79]''' Edward Yourdon, Larry L. Constantine. ''Structured Design: Fundamentals of a Discipline of Computer Program and System Design.'' Prentice–Hall, 1979.

Admin at 10:49, 17 July 2021

2021-07-17T10:49:33Z

← Older revision		Revision as of 10:49, 17 July 2021
Line 346:		Line 346:
	</blockquote>		</blockquote>

	=Encapsulation=		==Encapsulation==

	From '''[BMECHY07]''':		From '''[BMECHY07]''':

Admin at 10:49, 17 July 2021

2021-07-17T10:49:12Z

← Older revision		Revision as of 10:49, 17 July 2021
Line 344:		Line 344:

	Both coupling and cohesion are powerful tools in the design of modular structures, but of the two, cohesion emerges from extensive practice as more important.		Both coupling and cohesion are powerful tools in the design of modular structures, but of the two, cohesion emerges from extensive practice as more important.
			</blockquote>

			=Encapsulation=

			From '''[BMECHY07]''':
			<blockquote>
			"For abstraction to work, implementations must be encapsulated." '''[L87]'''. In practice this means that each class must have two parts: an interface and an implementation. The interface of a class captures only its outside view, encompassing our abstraction of the behavior common to all instances of the class. The implementation of a class comprises the representation of the abstraction as well as the mechanisms that achieve the desired behavior. The interface of a class is the one place where we assert all of the assumptions that a client may make about any instances of the class; the implementation encapsulates details about which no client may make assumptions.

			To summarize, we define '''encapsulation''' as follows:
			<blockquote>
			Encapsulation is the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation.
			</blockquote>

			Britton and Parnas '''[BP81]''' call these encapsulated elements the "secrets" of an abstraction.
	</blockquote>		</blockquote>

	=Bibliography=		=Bibliography=

			* '''[BMECHY07]''' Grady Booch, Robert Maksimchuk, Michael Engle, Jim Conallen, Kelli Houston, Bobbi Young. ''Object-Oriented Analysis and Design with Applications''. Pearson Education, 2007.
			* '''[BP81]''' K. Britton and D. Parnas. ''A-7E Software Module Guide''. Naval Research Laboratory, 1981.
	* '''[H10]''' Kevin Henney. ''97 Things Every Programmer Should Know''. O'Reilly, 2010.		* '''[H10]''' Kevin Henney. ''97 Things Every Programmer Should Know''. O'Reilly, 2010.
			* '''[L87]''' Barbara Liskov. Data Abstraction and Hierarchy. OOPSLA, 1987.
	* '''[M06]''' Alex Martelli. ''Python in a Nutshell'', second edition. O'Reilly, 2006.		* '''[M06]''' Alex Martelli. ''Python in a Nutshell'', second edition. O'Reilly, 2006.
	* '''[M97]''' Bertrand Meyer. ''Object-Oriented Software Construction'', second edition. Prentice Hall, 1997.		* '''[M97]''' Bertrand Meyer. ''Object-Oriented Software Construction'', second edition. Prentice Hall, 1997.

Admin at 07:12, 12 July 2021

2021-07-12T07:12:27Z

← Older revision		Revision as of 07:12, 12 July 2021
Line 111:		Line 111:
	</blockquote>		</blockquote>

	Rob Pike, who became one of the great masters of C, offers a slightly different angle in ''Notes on C Programming'' [~~Pike~~]:		Rob Pike, who became one of the great masters of C, offers a slightly different angle in ''Notes on C Programming'' '''[P89]''':
	<blockquote>		<blockquote>
	* Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so fon't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.		* Rule 1. You can't tell where a program is going to spend its time. Bottlenecks occur in surprising places, so fon't try to second guess and put in a speed hack until you've proven that's where the bottleneck is.