/**
* getRows.
* @param inData DataIn
* @param index int
* @return Data
* @throws Exception when something goes wrong
*/
public Data getRows(DataIn inData, int index)
Totally imaginary examples of things which never happen in real world software development projects.
Monday, March 28, 2011
Documentation is important
Tuesday, March 22, 2011
Keep your code readable
public void doSomething(Vector items) {
int j = 0;
while (j < items.size()) {
// 50 lines of code
if (0 == j && 1 < items.size()) {
break;
}
// 50 lines of code
j += (j + 1) == items.size() && 1 < items.size() ? -j : 1;
}
}
Friday, January 14, 2011
Deadline? What for?
The scenario:
- A planned project budget of some 25 million Euros
- A consortium of 20+ industrial partners (including all the really big global players in this area
- A project-discussion time of more than 6 months before the meeting described here
- 5 workdays until the final deadline for submitting the project proposal - no possibility of a late handin
- No coordinating partner yet
- Not even a very simple draft or outline of a proposal yet
Excerpt 1 of the consortium meeting: Trying to find a coordinating partner
... we have to agree on the coordinating partner, so please, who is willing to do it?
Why should we have a coordinating partner?
Because this is mandatory!
Are you sure?
Yes!
Sorry, we shouldn't waste our time on that, let's discuss it via email, we don't have to find the coordinator today. Let's just write a name into the proposal and then we'll see. We have more important things to discuss today...
Excerpt 2 of the consortium meeting: Trying to agree on a deadline
... we have 5 days left until we must submit our proposal - so all the partners have to describe their workpackages and send it to the coordinator, who will then compile the proposal
But we don't have a coordinator
Ok, that's right - so I'll coordinate this proposal compilation myself. Please send me your descriptions. And I would say, the deadline is in 2 days
Deadline? I don't think, we should have a deadline. We all do our best and when we're done, we'll send you the results
But when? Keep in mind that there's much work to do to make this proposal look good!
No, I'm against a deadline, what about the rest?
... nobody else said anything ...
Well, ok, then we obviously agree that we don't have a deadline. We'll send you our descriptions as soon as we have finished them
What do you think happened to the proposal? :-)
Thursday, January 6, 2011
Why would you use lock if you can take a bool...?
while(dangerous)
;
dangerous = true;
// operations in critical section here...
dangerous = false;
... as you can see, the people who invented lock(...) just think way too complicated - in reality it's much easier! You only have to know that one of the very important properties of bool variables is that several lines of code that use the same variable are compiled down to a single atomic operation :-)
Ah - and I forgot to mention the other important property: in case of an exception it is guaranteed that all bools are automatically set to false during stack unrolling... :-)
Saturday, December 11, 2010
When In Doubt, Do Nothing
Like in this example:
void OnItemClick(object sender, EventArgs e)
{
string selected;
try
{
selected = Parse(e.Item.Value);
}
catch (Exception ex)
{
Log("Clicked Item not found", ex);
throw;
}
switch (selected)
{
default:
break;
}
}
Thursday, December 2, 2010
It's so easy to define delimiters...
Requirement to be fulfilled: Two files have to be transfered over a TCP-connection. Both are zip-files and the transfer is a plain raw-data transfer.
Proposal of the client-side developer: "Just pack the info about the file-lengths into the header"
Answer of the server-side developer: "Are you crazy? Why should I do that? It's much better to just define a delimiter that is sent after the first file. Then you immediately know where the second file starts"
Question of the client-side developer: "But how would you define a delimiter? We work with raw data-transfer, so it isn't possible to define one that is guaranteed not to appear in the stream as real data"
Answer of the server-side developer: "Hah - just take qayxswedcvfrtgb - this one for sure does not appear in any zip-file"
... as a proof that the server-side developer was just plain wrong - not only theoretically but also practically - the client-side developer just took a bunch of the zip-files to be transfered and ran a grep for this string over them - guess what happened... sure there were several appearances of this "delimiter"...
... with this result in hands the client-developer tried to convince the server-developer again that the "delimiter"-solution is plain nonsense...
... and got the answer: "ok, this string seems to have been too short, we take qayxswedcvfrtgbnhzujm,kiol.- instead, then it works"
... needless to say what happened to the data transfer...
Saturday, November 27, 2010
Almighty Constructor...
int main(int argc, char* argv[])
{
FSim sim;
}
Huh?
For those of you with too little imagination - here's the explanation:
The constructor of the class FSim started and ran the whole simulator by constructing other objects, which themselves did the same. So the whole program was an incredibly long chain of constructors and quitting the program just let the innermost constructor run to completion, which in turn let all the others run to completion, which resulted in a constructed variable sim, which ended the program.
Only the best of all developers are able to write such extremely clever solutions!