Code Analysis Quotes

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified. It is often a mistake to make a priori judgments about what parts of a program are really critical, since the universal experience of programmers who have been using measurement tools has been that their intuitive guesses fail.

Beware of bugs in the above code; I have only proved it correct, not tried it.

The best way to prepare [to be a programmer] is to write programs, and to study great programs that other people have written. In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating systems.

No amount of source-level verification or scrutiny will protect you from using untrusted code.

In programming when you're making a change you have to know all the affected places, and you have to be able to model in your head what the performance impact will be.

If we wish to count lines of code, we should not regard them as "lines produced" but as "lines spent."

It's probably fair to say that the ratio of time our Connector developers spend in the debugger versus the Emacs buffer is higher than with most software.

It's true, I had hacked into a lot of companies, and took copies of the source code to analyze it for security bugs. If I could locate security bugs, I could become better at hacking into their systems. It was all towards becoming a better hacker.

Personally, I look forward to better tools for analyzing C++ source code.

The most effective debugging tool is still careful thought, coupled with judiciously placed print statements.

It would appear that the number of nonsense triplets is rather low, since we only occasionally come across them. However this conclusion is less secure than our other deductions about the general nature of the genetic code.

If the code does indeed have some logical foundation then it is legitimate to consider all the evidence, both good and bad, in any attempt to deduce it.

The future art historians are going to be software guys who are going to go into the depths of the code to find out what was changed hundreds of years before.

Simply put, when you have very large pieces of software, most of the tools look at the individual lines of code as text. It is often extremely powerful to look not at individual pieces of code but at a system as a whole.

If I needed to know about a security exploit, I preferred to get the information by accessing the companies' security teams' files, rather than poring over lines of code to find it on my own. It's just more efficient.

How do we know, then, when a code's been cracked?when we are right?when do we know if we have even received a message? Why, naturally, when, upon one set of substitutions, sense emerges like the outline under a rubbing; when a single tentative construal leads to several; when all the sullen letters of the code cry TEAM! after YEA! has been, by several hands, uncovered.

WhatsApp deliberately obfuscates their apps' binaries to make sure no one is able to study them thoroughly.