Let me start out by saying this is not a flame, or a personal attack. This is just me posting a link to some of the worst code I've seen in my life, which is pretty much the whole point of this site.
Okay let's just say there's this guy who wrote this "search engine" and he posted some of the code to his website. This code could hypothetically be found here.
It would be helpful to have some sort of search engine to search through the code for this search engine, because the code structure can best be described as a large bowl of spaghetti. One of the benefits of this coding style is that you get the speed of VB6 and the clarity of assembly language all rolled into one.
Some highlights:
1. No functions, but plenty of gotos and labels. All of the labels are given helpful names such as "line_13012".
2. A surprisingly large amount of comments, the majority of which are completely useless. Some of my favorites:
array_aaa(array_pos) = " " + Left(aaa, tt - 1) + " "
array_ooo(array_pos) = " " + Left(ooo, tt - 1) + " "
aaa = Mid(aaa, tt)
ooo = Mid(ooo, tt)
xxx = Mid(xxx, tt) 'january 21 2001
and
If III < 1 Then GoTo line_13628i 'should never happen
3. Not one, but two completely useless replacements for a boolean:
match_flag = "YES"
...
match_flag = "NO"
and (notice anything wrong with this one?)
If sscreen_saver = "Y" And sscreen_saver = "N" Then
If you listen closely while you read the code, you can almost hear Dijkstra weeping.
burnmp3s
@burnmp3s
Best posts made by burnmp3s
-
Functions Considered Harmful
-
RE: The Secretive Hidden InterNet Censors
@SpectateSwamp said:
Anyway a couple days ago (2) a trapper friend of my friend
called Him after receiving a call from some Official...The Real WTF<font face="verdana, arial" size="2">™ is your weird capitalization system. Generally you shouldn't capitalize pronouns unless you are referring to some sort of deity.
</font>
Latest posts made by burnmp3s
-
RE: Managing Exceptions in .NET
@ammoQ said:
Generally, in Java and .net, there is no "undefined behavior". If the phonebook returns null, and the calling program forgets the check, it will inevitably throw a null reference exception when it tries to access the object the first time.
Like I said, most of the time you will get a null reference exception right after the buggy call, but not always. For example, the null entry might be passed to a function that accepts null as a parameter. My point is that the fact that you get a null reference exception is not gauranteed, and the few times that you don't can be very nasty.
@ammoQ said:
If this is a multthreaded multiuser application, this option is prone to race conditions. Sooner or later, the entry will be removed by another thread between IsListed (true) and GetEntry (Exception); or it will be created between IsListed (false) and AddEntry (Exception).
We already talked about this, I would use locking in this case. I would probably do this by treating the phonebook as a resource, by implementing IDisposable so that you can use "using" to lock and unlock the phonebook like a file. Files are a good analogy, because they have the same issue (you can get FileExists (true) and still get FileOpen (Exception)). Also, if you are using it for a "multithreaded multiuser application", it sounds like you are just wanting ACID transactions. If so, I could just put the phonebook data in a database and let the database worry about most of the concurrency issues.
Anyway, all of this is getting far from my point: If I have a choice between returning null to represent an error and throwing an exception to represent an error, I will usually throw the exception.
-
RE: Managing Exceptions in .NET
@RiX0R said:
But that's why you don't do the IsListed test in such a case -- just do the lookup, and catch the exception if the lookup failed.
I for one love exceptions, and I use them exactly like burnmp3s.
For the record I don't actually use exceptions this way. The reason why I write functions like IsListed is to avoid having to do a try/catch to figure out if the code will throw an exception or not. For example, I will generally check if a file exists before opening it rather than just opening it and catching the FileNotFound error.
A lot of the exceptions that I throw in my code are never actually thrown during the execution of my programs. Throwing the EntryNotFound exception is a design decision for my PhoneBook class, but it makes sense to put it in even if I know I'm going to always use IsListed to make sure it never actually gets thrown. I know that might sound strange, but look at the .NET framework. There are many exceptions in the .NET classes are not really meant to be caught, they are just there in case you use the classes incorrectly.
Basically as I see it there are three ways to handle the Lookup failures:
1. Assume the client code will never try to lookup an entry that is not in the phonebook (after all, they can always check with IsListed). You could document this prominently in the function header. Inevitably somebody will put in code that forgets to check if an entry is listed, and you will get undefined behavior inside Lookup. This will most likely be difficult to debug and might do damage to the phonebook data.
2. Return null if the entry is not listed. Now the client has a choice: they can use IsListed so that Lookup never actually returns null, or they can forget about IsListed and just check to see if they get a null back. Again though, eventually someone will forget to check for null and the client code will get an unexpected null back. This will result in undefined behavior in the client code. Most of the time you will get a null reference exception in one of the next few lines, but sometimes the null can propagate and be very hard to track down.
3. Throw an exception if the entry is not listed. This time the client code can use IsListed to avoid the exception, or it can just forget about IsListed and check to see if it throws the exception. This time, if someone forgets to catch the exception, you either get an unhandled exception that crashes the program or (more likely) a high level catch block in the UI will tell the user that a missing phonebook entry caused the operation to abort. There is no chance of undefined behavior. Also, debugging is easy because you get a specific exception with a stack trace that tells you exactly what went wrong.
I almost always choose option 3. I write my code so that it avoids causing exceptions whenever possible, and the vast majority of my code contains no try/catch blocks. If an exception is thrown, either because of a bug or because I purposely planned to have it thrown in that situation, I have a safety net in the form of my high level exception handlers. I can't stress enough how effective this is for debugging, especially for debugging problems users are having. I usually write all of my exceptions to my support logs, so that if a user finds a bug that I can't duplicate I can just ask for the support logs. -
RE: Java vs VB .NET
@tster said:
@burnmp3s said:
The only reason people normally talk about interpreted vs. compiled is for two other issues: speed and portability. If an interpreted language can run as fast as C on every platform, people won't care whether it's interpreted or not.
They would if they were going to sell the software to thousands of people and they wanted to make it as hard as possible to modify or access the source code.
Yes security is a concern too, but in my opinion it's not nearly as important as the other two factors.
First of all, remember that interpreted != scripting. Sure if you send out your Python scripts to people, you are giving them the source code. Java on the other hand is also interpreted, but bytecode is much more similar to native machine code than it is to the source code.
Also, simply compiling to native machine code is not a very good security measure to prevent modifications. With relatively little effort, software cracking groups have removed copy protection schemes from nearly every game and application released in the last 10+ years.
-
RE: Java vs VB .NET
@Mikademus said:
@coobird said:
In both Java and .NET platforms, the source code is compiled to intermediate code (bytecode), which is handed over to a virtual machine (whether it be the JVM or the CLR) for execution. For all intents and purposes, I don't see a large difference in how the two platforms handle execution of code. I suppose the extent of compiling the bytecode into native code at runtime by JITing may be different by the two virtual machines, but whatever isn't being compiled by JIT is more or less being interpreted by the VM. I'm not sure how compiling to bytecode on Java would be "closer to compiled" as opposed to compiling to MSIL on .NET.If people say "Java is interpreted," I think there's some truth to it, as unless the bytecode is being converted into native machine code, it is interpreted.
The argument is is as usually only a failure to properly define what is really debated, and in this case peoples' ideas about what the "actual platform is" differ. Some see the platform as the virtual machine, and then Java and .NET are compiled languages, and some see the platform as the OS, and then they are interpreted languages. Programmers should read more philosophy of language and many irrelevant argumentations would be pre-empted (and philosophers should study some programming and they could take care of programming their own gadgets).
Don't forget that "native" machine code is not always a direct representation of the instructions that are actually run on your CPU. To take an extreme example, the Transmeta Crusoe processor translates x86 instructions into its own VLIW instructions on the fly.
The only reason people normally talk about interpreted vs. compiled is for two other issues: speed and portability. If an interpreted language can run as fast as C on every platform, people won't care whether it's interpreted or not.
-
RE: Programming style question
@fennec said:
Someone once proposed an elegant and effective way to improve the quality of code: prefix variables with something indicating their function. For instance, the prefix
ct
might indicate a counter. The proponent, Charles Simonyi of Microsoft, was originally from Hungary, and the pattern became known as Hungarian Notation (for more information about Hungarian Notation, see Resources).This is less pointless than prefixing by type, but I would hardly call it elegant or effective. How is ctMatch in any way better than matchCounter? Sure, using "ct" shaves off 5 characters, but now you have all of the usual Hungarian headaches. It's harder to read, you have to know what all of the prefixes mean, you can't have use the same prefix for similarly spelled words, etc.
-
RE: Programming style question
@jergosh said:
I can't remember ever seeing c used for an input character so I would shy away from that. I would recommend you use a more descriptive name. And although I've seen pos used on occassion, a more descriptive name would still be a benefit here. This one is more personal preference since it's still pretty easy to guess what it represents.
You've never seen while ((c = getchar()) != EOF) ? Whoa. You might want to have a glimpse at ANSI C by K&R. Also, http://www.google.com/codesearch?hl=en&lr=&q=%22char+c%22&btnG=Search
Just because a lot of people have done it doesn't mean its standard practice. Two of the worst possible variable names, "data2" and "stuff", also have many hits on google code search.
As for this thread being off topic, I would guess it's because most people here can't think of a programming reference that specifically warns against long variable names. Also, when you post something that people might not agree with (like your assertion that "pos" is a standard naming convention), you should expect people to post arguing that you are wrong.
-
RE: Programming style question
@RayS said:
For my sins however, I do use the e.g. txtFirstName naming convention in UI stuff (windows & web) purely because it makes intellisense group controls together by type.
The best thing I've found for this is to use "ui" as a prefix for all UI controls. Besides underscores for private variables, this is the only prefix I use in VB.NET.
The "ui" is nice because that way all of your UI controls are grouped together in one place in the massive Intellisense Form members list. I also always put some kind of indication of what type of control it is in the name. So for example, I might have uiUserNameLabel and uiUserNameTextBox, which show up next to each other in the list.
I think the normal way of doing it (txt,lbl,etc.) is annoying because you have to agree on a standard list for all controls, even the obscure and custom ones. Even for the more common ones, some people tend to use "cbo" for combo boxes, but other people use "cmb" or even "cbb". But by far the most annoying naming system is the "default" one (TextBox1,TextBox2,etc.).
-
RE: DB question (spec on DELETE)
I'm not a DB expert, but wouldn't this mean that you would have to filter every query you write to make sure you don't accidently find deleted data. This would probably negatively affect performance. Moving deleted rows into a special "deleted" table might be a better idea. Why are you trying to avoid DELETE anyway?
-
RE: Java vs VB .NET
@malfist said:
<FONT size=3><FONT face="Times New Roman">“It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.” Another saying that has been attributed to him is that, “Teaching BASIC should be a criminal offense.” </FONT></FONT>
You should remove these quotes. They are from this. Notice that your second quote is misquoted (he was talking about COBOL, not BASIC). He was basically saying that all of the popular languages of 1975 were flawed, he wasn't picking on BASIC in particular. Also note that 1975 basic is very different from present day VB.NET or even VB6. In those days GOTOs (as in "GOTO Considered Harmful") with line numbers were the norm.
Also you should footnote all of your references to your sources, or at least the ones you quote directly.
-
RE: The state of the TDWTF main page comments
@aikii said:
What do you think of slashdot's moderation system ?
For blogs, I personally like LifeHacker's system the best. You "sign up" by submitting a comment with whatever user name you want. If your comment is insightful, it gets posted and you get an email with account info for the user name you selected. Also, you are warned that your account may be taken away if you start posting dumb comments.
This greatly reduces the volume of comments and keeps the quality high.