Saturday, August 30, 2008

Open Source Code Review - A choice to name a method "Inscrutable"?

I've been reviewing various open source projects related to Amazon S3 and discovered the excellent Resourceful library and the related project SpaceBlock.  The following code is a utility class in the SpaceBlock project. 
 
The method I found offensive was named "Inscrutable" and is located in the class named F.  The definition of "Inscrutable" from dictionary.com is "incapable of being investigated, analyzed, or scrutinized; impenetrable."  This reminds me of a quote I heard 25 years ago from an old mainframe programmer at Westinghouse.  I was complaining about the understandability of his VMS code and he said "If it was hard to write, it should be hard to understand".  I couldn't have disagreed with him more.  I believe in intellectual manageability of the code you write.  You don't write code for yourself or the compiler.  You write it for other people.  By naming a function "Inscrutable" you are flipping me and everyone else the bird! 
 
I guarantee this will happen to you one day (if it has not already).  You will be reviewing your own code for a bug fix and discover a particularly tricky piece of code that you didn't comment or name your function properly.  If you were so arrogant as to name your method "YouAreTooStupidToUnderstandHowThisWorksSoDontEvenTry" you will be essentially flipping yourself the bird!  You will then end up spending way too much time figuring out and reflecting on exactly you were thinking when you wrote that code.
 
Now, I'm not saying I'm not guilty of doing similar complexities with my code.  In fact, I can hear my co-workers now shouting over the cubical walls "Hey, isn't that the pot calling the kettle black".  I'm posting this as a reminder to myself and all developers to never do something this blatant and egotistic as this in our code.
 
I am not slamming these projects. I think they are well written and have a great coding style. I plan to use them in the future.
 

C# 4.0: Meet the Design Team

Anders and crew meet in the room where C# was birthed and talk about the future.


C# 4.0: Meet the Design Team

Wednesday, May 07, 2008

Edward Tufte One Day Seminar

Yesterday I attended a one day seminar in Arlington, VA presented by Edward Tufte.

It was a great presentation and I picked up all four of his books.

quotes and general notes:

Great designs are transparent

Never segregate data by the mode of production.

Show all the data, it provides credibility.

We should be concerned with the quality of thought.

Don't use lowest common denominator design or you will have an intellectual disaster.

Tables out perform graphs for data less than 1000 points.

Screens should be 95% content and 5% administrative debris (scrollbars, toolbars, etc.).  Measure it.

Design the surface first.  Outside-In design.  iPhone designed the hardware platform before the software.  iPhone has one of the highest DPI of any consumer device.

Don't provide an application solution.

Leave the UI alone once it's done.

There is no relationship between the amount of information and the ability to process.  The human eye can process 10mbit/sec.

Don't be an original.  Steal a good design.

Consider a "super graph".  It unifies and relates the audience to the data or theme.

Increase information throughput

Examine how newspapers report data and clone it. Examine "Nature" magazine.

Multivariant problems are the only interesting problems.

Progress in technology is measured in resolution

Don't use legends on graphs.  Put the text on the line.

Maximize content reasoning and minimize decoding

"We want to be approximately right rather than absolutely wrong"

Use Gill Sans Font

Annotate everything

about presentations

  • Show up early for your own presentation to meet people, to show a gracious gesture, and to hand out materials early.
  • Use presentations as a review of the material distributed prior to the meeting.  Maybe simply ask "Are there any questions?" and end the meeting.
  • Use Power Point as a projector operating system
  • Give out handouts before meeting - people can read 2x-4x times faster than you can talk.
  • What is the problem?
  • Who cares? the relevance
  • The solution
  • Have a summary
  • Say you will answer questions when they are done reading
  • Use sentences.  No laundry lists of nouns.  Sentences for you to think causally.
  • Don't use bullet reveals.
  • Practice in front of a friend or a video camera
  • Turn off the video and listen to the audio
  • Ask a trusted friend for criticisim
  • Never begin with an all purpose joke
  • Never apologize at the start of the presentation
  • Stay out of the first person during the introduction
  • Stay on content
  • Finish early

Wednesday, March 26, 2008

Quote of the day

Wednesday, January 30, 2008

Playing with the .NET FCL symbols and source code

I’m playing with the debug symbols for the .NET framework and came across some interesting things in code.

Dropping back to memory manipulation for performance from the String class

// Returns the entire string as an array of characters.

unsafe public char[] ToCharArray() {

// huge performance improvement for short strings by doing this

int length = Length;

char[] chars = new char[length];

if (length > 0)

{

fixed (char* src = &this.m_firstChar)

fixed (char* dest = chars)

wstrcpyPtrAligned(dest, src, length);

}

return chars;

}

AMD Specific code!

#if AMD64

// for AMD64 bit platform we unroll by 12 and

// check 3 qword at a time. This is less code

// than the 32 bit case and is shorter

// pathlength

while (length >= 12)

{

if (*(long*)a != *(long*)b) break;

if (*(long*)(a+4) != *(long*)(b+4)) break;

if (*(long*)(a+8) != *(long*)(b+8)) break;

a += 12; b += 12; length -= 12;

}

#else

while (length >= 10)

{

if (*(int*)a != *(int*)b) break;

if (*(int*)(a+2) != *(int*)(b+2)) break;

if (*(int*)(a+4) != *(int*)(b+4)) break;

if (*(int*)(a+6) != *(int*)(b+6)) break;

if (*(int*)(a+8) != *(int*)(b+8)) break;

a += 10; b += 10; length -= 10;

}

#endif