The code so bad you won't hire
- ParadigmShifter
- Manic Miner
- Posts: 873
- Joined: Sat Sep 09, 2023 4:55 am
Re: The code so bad you won't hire
Microsoft had to still support loads of broken code in Windows 95 so that DOS games that used questionable decisions would still run on Windows 95 which could multitask DOS. Backwards compatibility was of course very important to them when selling their new OS.
Re: The code so bad you won't hire
When your Amazon purchase of extra salt for your water softener is delayed by four days, that's usually due to compatibility with Microsoft Golf 95.ParadigmShifter wrote: ↑Wed Jan 03, 2024 1:09 pm Microsoft had to still support loads of broken code in Windows 95 so that DOS games that used questionable decisions would still run on Windows 95 which could multitask DOS. Backwards compatibility was of course very important to them when selling their new OS.
Anyway I was asking the great ROM man AOwen how I can tell a +2 from a +2a/+3 by PEEKing ('cause I need to do something in BASIC), and he said: check if PEEK 109 is 40. This story is longer but I need to pee.
-
- Manic Miner
- Posts: 749
- Joined: Mon Nov 26, 2018 1:07 pm
- Location: UK
- Contact:
Re: The code so bad you won't hire
That's the real warning from history.
Manic Miner with Physics: https://stephensmith.itch.io/manic-destruction
- ParadigmShifter
- Manic Miner
- Posts: 873
- Joined: Sat Sep 09, 2023 4:55 am
Re: The code so bad you won't hire
First place I worked at had no source control at all, which was fun when it came to merging code together lol.
2nd place used VSS which was terrible but better than nothing.
3rd place I worked at (not games) the lead programmer refused to use source control because it was a risk other people would steal or modify his code. We had to get one of the hired contractors to tell him to use source control because he wouldn't listen to me
I refused to work with that coder after a while since I was supposed to be doing a windows CE version of his driver (which involved moving a lot of code around since the order of initialisation of static objects was reversed in CE as opposed to Windows NT, and there was code which relied on initialisation order of globals (which is bad practice anyway). Every time he updated the code he would stomp on my fixes that would work on both NT and CE so after a few rounds of that I asked to be moved to another project.
At that company we also had a presentation from a guy selling source control software but when I asked him how it copes with multiple checkouts of the same file (requires merging etc.) he said it prevented you from doing that lol so again we used VSS (which we already had for free cos the MSDN subscription thing came with VSS).
2nd place used VSS which was terrible but better than nothing.
3rd place I worked at (not games) the lead programmer refused to use source control because it was a risk other people would steal or modify his code. We had to get one of the hired contractors to tell him to use source control because he wouldn't listen to me
I refused to work with that coder after a while since I was supposed to be doing a windows CE version of his driver (which involved moving a lot of code around since the order of initialisation of static objects was reversed in CE as opposed to Windows NT, and there was code which relied on initialisation order of globals (which is bad practice anyway). Every time he updated the code he would stomp on my fixes that would work on both NT and CE so after a few rounds of that I asked to be moved to another project.
At that company we also had a presentation from a guy selling source control software but when I asked him how it copes with multiple checkouts of the same file (requires merging etc.) he said it prevented you from doing that lol so again we used VSS (which we already had for free cos the MSDN subscription thing came with VSS).
Re: The code so bad you won't hire
Before we had SourceSafe we used to swap CDs in the post. This isn't a funny joke, this was true in about 2002.
I love how this thread has taken off, and isn't about the Spectrum at all. I think HackerNews vultures are starting to hover over us.
Re: The code so bad you won't hire
POKE 23658,8
IF INKEY$="o"
Turn caps lock on then check for lower case letters.
I'm looking at you Sqij
IF INKEY$="o"
Turn caps lock on then check for lower case letters.
I'm looking at you Sqij
Re: The code so bad you won't hire
Also:ParadigmShifter wrote: ↑Wed Jan 03, 2024 1:38 pm the lead programmer refused to use source control because it was a risk other people would steal or modify his code
1. Better don't do it than do it wrong. (ARGUABLE)
2. ParadigmShifter clearly invented source control, he is Linus Torvalds. Can't be, we know he writ Game Boy stuff. Why else would hang around a Z80 forum.
3. more beer
Last edited by equinox on Wed Jan 03, 2024 1:46 pm, edited 1 time in total.
- ParadigmShifter
- Manic Miner
- Posts: 873
- Joined: Sat Sep 09, 2023 4:55 am
Re: The code so bad you won't hire
Main thing wrong with VSS (apart from corrupting the database on a regular basis) was that commits were not atomic so one person could be checking in a file while the same file was pending a checkin, which would lead to bad merges or other such stuff. SVN either commits everything or fails half way through and commits nothing (making you update files modified you are about to check in) which is better.
At one time (not when I was there) they used to have a special VSS hat you had to wear when checking in so that no-one else would check in at the same time lol. Then they wrote a program which implemented a queue so you had to wait until you were at the top of the queue before checking in... was better than wearing a hat lol.
At one time (not when I was there) they used to have a special VSS hat you had to wear when checking in so that no-one else would check in at the same time lol. Then they wrote a program which implemented a queue so you had to wait until you were at the top of the queue before checking in... was better than wearing a hat lol.
Re: The code so bad you won't hire
Yes I saw this happen.ParadigmShifter wrote: ↑Wed Jan 03, 2024 1:46 pm commits were not atomic so one person could be checking in a file while the same file was pending a checkin, which would lead to bad merges
You wonder "how come you could possibly have SQL Server but not understand atomicity".
The answer is: BORING DEPARTMENTAL SHIZZ
i guess
On the up-side I can still connect to an imaginary "OLEDB" thing that nobody has used since 1994. It still works mate. (although SQL Server recently dropped support for Hadoop, draw your own conclusions)
Re: The code so bad you won't hire
Yes, in the Perl world, see "pumpking" (you can't check in code unless you have got the pumpkin toy at your desk): https://en.wiktionary.org/wiki/pumpkingParadigmShifter wrote: ↑Wed Jan 03, 2024 1:46 pm they used to have a special VSS hat you had to wear when checking in so that no-one else would check in at the same time
It's dumb but clearly somebody at that time realised "software flags can go wrong, but fluffy toys can't".
Last edited by equinox on Wed Jan 03, 2024 1:52 pm, edited 1 time in total.
- ParadigmShifter
- Manic Miner
- Posts: 873
- Joined: Sat Sep 09, 2023 4:55 am
Re: The code so bad you won't hire
Not using source control on a multi-person project is just madness. You can just about get away with it on a single person project but it's still very useful to have since it makes rollbacks much easier.
No I'm not Linus (who didn't invent source control anyway of course) and I've never worked on the Gameboy. I taught myself Z80 coding in 2004 or so I think since I didn't learn it when I had a Speccy (although I tried to) and after many years of game coding I thought it would be fun to write a Spectrum game in machine code since I never had before(and I now knew a lot more about writing games of course and knew C very well).
- Einar Saukas
- Bugaboo
- Posts: 3196
- Joined: Wed Nov 15, 2017 2:48 pm
Re: The code so bad you won't hire
If it's OK to post non-Spectrum bad code, then I have hundreds of examples. All of them from actual production code at multinational companies (but I won't tell which ones).
For instance:
return !(getPk() != null ? !getPk().equals(contract.getPk()) :
contract.getPk() != null);
For instance:
return !(getPk() != null ? !getPk().equals(contract.getPk()) :
contract.getPk() != null);
Re: The code so bad you won't hire
First thought was "don't call the method twice" -- not because it it's expensive (I know each branch will only call it once) but it's just damn harder to read. Then:Einar Saukas wrote: ↑Wed Jan 03, 2024 1:53 pm If it's OK to post non-Spectrum bad code, then I have hundreds of examples. All of them from actual production code at multinational companies (but I won't tell which ones).
For instance:
return !(getPk() != null ? !getPk().equals(contract.getPk()) :
contract.getPk() != null);
x = contract.getPk();
return !(getPk() != null ? !getPk().equals(x) : x != null);
I guess I'm missing something here like "OBVIOUSLY IT'S A TAUTOLOGY" but it's not an easy read. Maybe we can assume that (contract==this) so we are wasting time evaluating against self? Not clear from the post.
Might be drunk though.
Post more.
Re: The code so bad you won't hire
Still not come to a firm explanation on why the teletext adapter ROM is riddled with relative conditional jumps to other jumps/calls like these
Code: Select all
LD (HL),A
CP (HL)
JR NZ,init_memory_0
JP init_48k
init_memory_0:
JP init_16k
- Einar Saukas
- Bugaboo
- Posts: 3196
- Joined: Wed Nov 15, 2017 2:48 pm
Re: The code so bad you won't hire
The code above is simply doing this:Einar Saukas wrote: ↑Wed Jan 03, 2024 1:53 pm return !(getPk() != null ? !getPk().equals(contract.getPk()) :
contract.getPk() != null);
return Objects.equals(getPk(), contract.getPk());
Last edited by Einar Saukas on Wed Jan 03, 2024 2:15 pm, edited 1 time in total.
- Einar Saukas
- Bugaboo
- Posts: 3196
- Joined: Wed Nov 15, 2017 2:48 pm
Re: The code so bad you won't hire
Another:
Code: Select all
if (currentelement.intValue() + linesperpage.intValue() < size.intValue())
currentelement = Integer.valueOf(currentelement.intValue() + linesperpage.intValue());
else
currentelement = Integer.valueOf(currentelement.intValue() + linesperpage.intValue());
Code: Select all
if (isDebit(Long.parseLong(prop.getProperty("DTY_Id")))) {
amount = amount.add(new BigDecimal(prop.getProperty("amount")));
} else {
amount = amount.add(new BigDecimal(prop.getProperty("amount")));
}
Last edited by Einar Saukas on Wed Jan 03, 2024 2:18 pm, edited 1 time in total.
- ParadigmShifter
- Manic Miner
- Posts: 873
- Joined: Sat Sep 09, 2023 4:55 am
Re: The code so bad you won't hire
That may make sense if there is conditional assembly involved which does something like write a log message before jumping to init_16k (in a debug build only) I guess.Guesser wrote: ↑Wed Jan 03, 2024 2:06 pm Still not come to a firm explanation on why the teletext adapter ROM is riddled with relative conditional jumps to other jumps/calls like these
Code: Select all
LD (HL),A CP (HL) JR NZ,init_memory_0 JP init_48k init_memory_0: JP init_16k
LD (HL), A
CP (HL)
is stranger, why not just OR A or CP A unless HL is changed in an interrupt routine (which would be bad).
Probably most bad ASM is produced by old compilers which weren't very good at optimising code and such though. You should only have to read (HL) again if the memory is volatile.
EDIT: Some stuff has to use relative jumps (e.g. relocatable code - so you can end up with "jump ladders" if you need to jump more than 128 bytes away) but that doesn't seem to be the case there since it does an absolute jump as well.
Last edited by ParadigmShifter on Wed Jan 03, 2024 2:22 pm, edited 2 times in total.
Re: The code so bad you won't hire
I'm being "devil's advocate", but considering that it's teletext, is there a case to say that they knew there would be future features, and wanted to reserve some space?
Re: The code so bad you won't hire
side effectsEinar Saukas wrote: ↑Wed Jan 03, 2024 2:10 pm The code above is simply doing this:
return Objects.equals(getPk(), contract.getPk());
Re: The code so bad you won't hire
I should say the apparent blind spot for most of the conditional branching instructions are by far not the only bizarre thing in the code.ParadigmShifter wrote: ↑Wed Jan 03, 2024 2:17 pm is stranger, why not just OR A or CP A unless HL is changed in an interrupt routine (which would be bad).
Probably most bad ASM is produced by old compilers which weren't very good at optimising code and such though. You should only have to read (HL) again if the memory is volatile.
Some small snippets get copied to RAM before execution, but this pattern is throughout the code. The best theory anyone could come up with last time was that the author had this habit from some ancient processor where the only conditional instructions were fixed skips.ParadigmShifter wrote: ↑Wed Jan 03, 2024 2:17 pm EDIT: Some stuff has to use relative jumps (e.g. relocatable code - so you can end up with "jump ladders" if you need to jump more than 128 bytes away) but that doesn't seem to be the case there since it does an absolute jump as well.
I gather this ROM was thrown together in a hurry to get something working properly after the complicated telesoftware system for the previous version didn't materialise. There's plenty of space left in the ROM where chunks of the original are still present unused!
Re: The code so bad you won't hire
This one reminds me of a report I inherited many years ago. It was run via a VB application, populating millions of rows of data from SQL Server into POCO collections. It would then split these millions of records into granular POCO collections containing tens of millions of objects. As you can imagine RAM was annihilated. A date range was part of the search criteria but that didn't matter to the original developer - it just grabbed everything from the several-million row table, broke it down into the objects, and then filtered the date range (and a couple of other filters) to the results. This original table had around 10,000 records added to it daily. It took easily 2 hours for this daily report to be run and would only get worse as time went on.
Of course the first thing I did was only grab the data required from the date range. That whittled it down to about 20 minutes. Then as I delved further into it, it was obvious the entire thing could be done via a Stored Procedure and all the VB code had to do was display the results. I converted a report that took over two hours into one that took 5 seconds. I ran them side by side - exactly the same results.
Farmed the app out to all users and the next day I'm inundated with complaints. Wasn't that it didn't work, it worked too well. The general consensus was that because it was returning so quickly it could not possibly be correct. I proved it was correct with side-by-side comparisons. Didn't matter - it's far too quick so it has to be inaccurate. Okay, leave it with me...
I added a Sleep thread to the very end. 15 minutes of the application doing absolutely naff all. Everyone's now happy.
F**king people...
ZX Spectrum Reviews REST API: http://zxspectrumreviews.co.uk/
Re: The code so bad you won't hire
This isn't a real anecdote and you may have seen it the same place I did (DailyWTF??) but yes, there was a time when you could stick a 5-second delay in your code, and then come back later and get paid again to "improve performance".
Interestingly I sent out a doc today about improved performance. But I have a tiny shred of self-respect (despite being a Spectrum BASIC programmer) and explained what I did, all the ugly indexes and everything.
Re: The code so bad you won't hire
Edit: I'm being an idiot...
Last edited by Vampyre on Wed Jan 03, 2024 3:01 pm, edited 1 time in total.
ZX Spectrum Reviews REST API: http://zxspectrumreviews.co.uk/
Re: The code so bad you won't hire
Relax, I was apologising for my own story, not yours. Now I can see how it looked bad. But just re-read the "this" as "the thing I'm about to introduce", and the "shred of self-respect" as the traditional British self-deprecation. Don't be mad at me. Total misunderstanding.