May 28, 2006

bug; alvorlighet, hyppighet, omfang, risiko

kanskje noko å få inn i bug-rapport, dvs alle desse sidene ved ein bug. 
dvs, truleg berre risiko som manglar hjå oss.

My life as a Code Economist
Should we fix this bug or not?
There are four questions to ask yourself about every bug:

Question One
When this bug happens, how bad is the impact?  Severity

Question Two
How often does this bug happen?   Frequency

Question Three
How much effort would be required to fix this bug?   Cost

Question Four
What is the risk of fixing this bug?    Risk

Two of them are "customer questions", and the other two are "developer questions".

i tillegg såg eg i ein kommentar:

"But the most important question of all is missing:
Question 0. Do you know exactly what is causing the bug, and how?"


Lint4j

er dette verdt å vurdera å ta i bruk?

Lint4j Overview - Lint4j: "Lint4j ('Lint for Java') is a static Java source and byte code analyzer that detects locking and threading issues, performance and scalability problems, and checks complex contracts such as Java serialization by performing type, data flow, and lock graph analysis.

Lint4j was created to help software developers detect defects and security vulnerabilities before writing the first test case. Lint4j saves time during code reviews as well, so developers can focus on getting business logic right. The Ant and Maven plugins enable easy integration into continuous builds with Cruise Control, AntHill and others."

elles:

May 25, 2006

site optimization - inkl tabell vs css

ein del anna interessant der også - noko visste eg og anna hadde eg ikkje tenkt så mykje på...

Site Optimization Tutorial
".... table-based layouts are the de facto Web standard, and foremost because table-heavy designs have a nasty reputation for poor performance.

And CSS layout? It's faster, better, and smarter.
....
Even though pure CSS positioning is the ideal way to lay out a page, it can make your site look funny (if not ugly) for Internet Explorer 4 and Netscape 4.x users. That's still a fair enough shake of the Web audience. And while you can design CSS that degrades nicely in older browsers, it still tends to look, well, degraded. If what you want is the most cross-browser, cross-platform, business-friendly design solution, you still have to lay things out on the table.
...
CSS is cooler. And smaller. And in the long run, its better.
....
[But] Let's face it, sometimes right-now compatability trumps future-compatability.
....
Unfortunately, tables also increase the time it takes to display a Web page, and some times by a substantial amount.
....
[next page]
As tables get bigger, and nested into one another, the amount of info that needs processing increases exponentially.
....
Basically, you still need to do whatever you can to optimize table code. Or, better yet, avoid it altogether.
....
Accelerating fixed-width tables .... a CSS-1 style of {table layout: fixed} to a fixed-width table speeds up the display process in Netscape 6+ and IE5+.
....
[code example: ] table style="table-layout: fixed;" width="600"
....
Now, don't go abusing the browser's trust! If you apply the {table layout:fixed} style incorrectly, with WIDTHS that don't quite add up, the browser will catch the error during the rendering process and start things over from scratch.
....
[next page]
One old-school trick works, though — remembering that lots of little tables appear to render faster than one big, many-rowed table.
....
HTML editors ... produce amazingly inefficient code.
....
One notorious culprit associated with slow-to-the-screen Web pages has always been the nested table.
....
browsers have to work doubletime on tables. Unlike most page elements, tables absolutely require two passes of browser "reflow" (layout code-crunching)
....
A single-nested table requires two passes, plus one more, because the inner table must be partially re-rendered during outer table's rendering process. Nest three tables inside one another, and that makes for five passes of reflow. Nest five levels deep, and the browser loops through reflow routines nine times.
....
So avoid using nested tables whenever possible, even if it means making minor alterations or simplifications to page layout.
....
Even though table rendering speed issues are less problematic on modern PC hardware, table layouts still hamper screen readers and other accessibility-enhanced browsers. Nested tables doubly so. We're building Web pages here, not those little Russian dolls."

May 23, 2006

Coding Horror: Code Smells

Eit utvalg av "code smells"...

Coding Horror: Code Smells: "the most important guideline is to watch for warning signs in your own code-- so called 'code smells'"
....
  • Comments: There's a fine line between comments that illuminate and comments that obscure. .... Do they explain "why" and not "what"?

  • Long Method
    Sometimes length is justified, but all things being equal, a shorter method is easier to read, easier to understand, and easier to troubleshoot. ....

  • Long Parameter List
    The more parameters a method has, the more complex it is. Limit the number of parameters you need in a given method, or use an object to combine the parameters.

  • Duplicated code
    Duplicated code is the bane of software development ....

  • Large Class
    Large classes, like long methods, are difficult to read, understand, and troubleshoot. Does the class contain too many responsibilities? ....

  • Type Embedded in Name
    Avoid placing types in method names ....

  • Uncommunicative Name
    Does the name of the method succinctly describe exactly what that method does? If not, rename it or rewrite it. ....

  • Dead Code
    Ruthlessly delete code that isn't being used. That's why we have source control systems.

  • Speculative Generality
    Write code to solve today's problems, and worry about tomorrow's problems when they actually materialize. Everyone loses in the "what if.." school of design. You (Probably) Aren't Gonna Need It.

  • Temporary Field
    Watch out for objects that contain a lot of optional or unnecessary fields. If you're passing an object as a parameter to a method, make sure that you're using all of it and not cherry-picking single fields. ....

  • Shotgun Surgery
    A change in one class requires cascading changes in several related classes. Consider revamping your design so that the change is limited to a single class.

May 22, 2006

Coding Horror: Recommended reading for developers

Coding Horror: Recommended reading for developers: "Recommended reading for developers"

nokon av desse har me snakka om før, men det er vel berre eit bra teikn...

May 16, 2006