Check Your Code First before Looking to Blame Others - Revision history

Kevlin: Check your code first before looking to blame others moved to Check Your Code First before Looking to Blame Others

Kevlin — Sun, 19 Jul 2009 02:20:07 GMT

Check your code first before looking to blame others moved to Check Your Code First before Looking to Blame Others

←Older revision

Revision as of 02:20, 19 July 2009

Allankelly at 10:12, 15 July 2009

Allankelly — Wed, 15 Jul 2009 10:12:08 GMT

←Older revision		Revision as of 10:12, 15 July 2009
Line 7:		Line 7:
	Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)		Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)

-	Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release.	+	Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; explain it to someone else; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release.

	Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.		Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.
Line 15:		Line 15:
	As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.		As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.

-	Multi-threaded problems are another source of ~~bug~~ to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.	+	Multi-threaded problems are another source of bugs to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.

	So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."		So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."

Kevlin at 12:11, 13 July 2009

Kevlin — Mon, 13 Jul 2009 12:11:05 GMT

←Older revision		Revision as of 12:11, 13 July 2009
Line 1:		Line 1:
	Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken.		Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken.

-	Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common ~~that~~ we might like to believe.	+	Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common than we might like to believe.

	I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.		I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.
Line 7:		Line 7:
	Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)		Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)

-	Given how rare compiler bugs are you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; look out for stack corruption and variable type mismatches; try the code on different machines and different build ~~targets~~, such as debug and release.	+	Given how rare compiler bugs are, you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; look out for stack corruption and variable type mismatches; try the code on different machines and different build configurations, such as debug and release.

	Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.		Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.
Line 13:		Line 13:
	When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They maybe doing something you never thought of or are doing something in a different order.		When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They maybe doing something you never thought of or are doing something in a different order.

-	As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler ~~then~~, it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.	+	As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler, then it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.

-	Multi-threaded problems are another source of bug to turn hair gray and ~~have one~~ screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.	+	Multi-threaded problems are another source of bug to turn hair gray and induce screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.

	So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."		So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."

Kevlin at 21:43, 1 February 2009

Kevlin — Sun, 01 Feb 2009 21:43:25 GMT

←Older revision		Revision as of 21:43, 1 February 2009
Line 1:		Line 1:
	Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken.		Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken.

-	Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, ~~they~~ exist, but they are far less common that we might like to believe.	+	Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, these bugs exist, but they are far less common that we might like to believe.

-	I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.	+	I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many more times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.

	Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)		Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)

-	Given how rare compiler bugs are you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries and version numbers; look out for stack corruption and variable type mismatches; try the code on different machines and different build ~~types~~ such as debug and release ~~if you use these~~.	+	Given how rare compiler bugs are you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies, so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries, and version numbers; look out for stack corruption and variable type mismatches; try the code on different machines and different build targets, such as debug and release.

-	Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them ~~– then~~ so too might tools from the same vendor.	+	Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them — so too might different tools from the same vendor.

-	When someone else is reporting a problem ~~that~~ you cannot duplicate go and see what they are doing. They maybe doing something you never thought of or doing something in a different order.	+	When someone else is reporting a problem you cannot duplicate, go and see what they are doing. They maybe doing something you never thought of or are doing something in a different order.

-	As a personal rule if I have a bug I ~~can’t~~ pin down, and ~~I’m~~ starting to think ~~its~~ the compiler then ~~its~~ time to look for stack corruption. This is especially true if adding ~~tracing~~ code makes it move around.	+	As a personal rule if I have a bug I can't pin down, and I'm starting to think it's the compiler then, it's time to look for stack corruption. This is especially true if adding trace code makes the problem move around.

-	Multi-threaded problems are ~~the other type~~ of bug ~~that~~ turn hair ~~grey~~ and have one screaming at the machine. All the recommendations ~~about~~ simple code are ~~10 times greater~~ when a system is multi-threaded. Debugging and ~~even~~ unit tests cannot be relied on find bugs so simplicity of design is paramount.	+	Multi-threaded problems are another source of bug to turn hair gray and have one screaming at the machine. All the recommendations to favor simple code are multiplied when a system is multi-threaded. Debugging and unit tests cannot be relied on to find such bugs with any consistency, so simplicity of design is paramount.

-	So before you rush to blame the compiler remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," ~~rather than~~ Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."	+	So before you rush to blame the compiler, remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," and prefer it to Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."

	By [[Allan Kelly]]		By [[Allan Kelly]]

Allankelly at 14:14, 1 February 2009

Allankelly — Sun, 01 Feb 2009 14:14:57 GMT

←Older revision		Revision as of 14:14, 1 February 2009
Line 18:		Line 18:

	So before you rush to blame the compiler remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," rather than Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."		So before you rush to blame the compiler remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," rather than Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."
		+
		+	By [[Allan Kelly]]
		+
		+	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

Allankelly: New page: Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken. Yet in truth it is very ...

Allankelly — Sun, 01 Feb 2009 13:01:13 GMT

New page: Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken. Yet in truth it is very ...

New page

Developers — all of us! — often have trouble believing our own code is broken. It is just so improbable that, for once, it must be the compiler that's broken.

Yet in truth it is very (very) unusual that code is broken by a bug in the compiler, interpreter, OS, app server, database, memory manager, or any other piece of system software. Yes, they exist, but they are far less common that we might like to believe.

I once had a genuine problem with a compiler bug optimizing away a loop variable, but I have imagined my compiler or OS had a bug many times. I have wasted a lot of my time, support time, and management time in the process only to feel a little foolish each time it turned out to be my mistake after all.

Assuming the tools are widely used, mature, and employed in various technology stacks, there is little reason to doubt the quality. Of course, if the tool is an early release, or used by only a few people worldwide, or a piece of seldom downloaded, version 0.1, Open Source Software, there may be good reason to suspect the software. (Equally, an alpha version of commercial software might be suspect.)

Given how rare compiler bugs are you are far better putting your time and energy into finding the error in your code than proving the compiler is wrong. All the usual debugging advice applies so isolate the problem, stub out calls, surround it with tests; check calling conventions, shared libraries and version numbers; look out for stack corruption and variable type mismatches; try the code on different machines and different build types such as debug and release if you use these.

Question your own assumptions and the assumptions of others. Tools from different vendors might have different assumptions built into them – then so too might tools from the same vendor.

When someone else is reporting a problem that you cannot duplicate go and see what they are doing. They maybe doing something you never thought of or doing something in a different order.

As a personal rule if I have a bug I can’t pin down, and I’m starting to think its the compiler then its time to look for stack corruption. This is especially true if adding tracing code makes it move around.

Multi-threaded problems are the other type of bug that turn hair grey and have one screaming at the machine. All the recommendations about simple code are 10 times greater when a system is multi-threaded. Debugging and even unit tests cannot be relied on find bugs so simplicity of design is paramount.

So before you rush to blame the compiler remember Sherlock Holmes' advice, "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth," rather than Dirk Gently's, "Once you eliminate the improbable, whatever remains, no matter how impossible, must be the truth."