What's the weirdest coding practice you've seen?

How about this:

Start with several CSS files called (for example) grid-768.css, grid-1024.css, etc.

Legacy is as legacy is, and they ended up with grid-768 starting with a media query for 790px widths.

Each stylesheet was filled with classes like .fl-17 { width: 17px; }, .fl-18 { width: 18px ; } and so on all the way up to 1920px. Those styles were liberally added to elements by the CMS.

Legacy is as legacy is, and they ended up with values like .fl-200 { width: 257px; } and so on.

I believe this was all to "avoid using inline styles".

Years ago I received an old C# legacy project where every method was catching all exceptions inside it, wrapping them in a new Exception, and rethrowing them:

void Foo(...)
{
    try
    {
        // ...
    }
    catch (Exception e)
    {
        throw new Exception("Exception thrown at Foo", e);
    }
}

void Bar(...)
{
    try
    {
        // ...
    }
    catch (Exception e)
    {
        throw new Exception("Exception thrown at Bar", e);
    }
}

void Baz(...)
{
    try
    {
        // ...
    }
    catch (Exception e)
    {
        throw new Exception("Exception thrown at Foo", e);
    }
}

Some guys from a company asked for help with some PHP code and I noticed something weird with the comments.

Keep in mind that this was a production application with decades of usage.

They were writing their names in each added/edited line, including commenting old lines, because no one there even knew what git is.

It gets worse: editing directly into production code.

Adding your name to the code you created.

/**
 * @author Alice
 */
public class FizzBuzz {
}

Are people supposed to append their name when they add/remove/change code? What if at some point all the code was changed an nothing of Alice's work is there, is he still an author? What if Bob added more code and appended his name, how do I know if it was Alice or Bob who added the code. Maybe it was Clive do didn't sign his name.

It's even worse in the more "recent" years, because we use version control and can see who changed what up to the byte.

I had to write macros that interacted with a Windows mainframe client to scrape and/or update data. The automation code was written in VBA and only worked if run from Access. Then we needed it to run from Excel, so I wrote the code to open Access from Excel, not to use a database, but to send commands to the mainframe client. I had no concept of good, bad, right, or wrong. Sort of like Jurassic Park - I didn't care if I should, only if I could.

Worst? Well, there's a lot of legacy VB6 code I've seen that would qualify for that. Big, monolithic, blocks of spaghetti code, inconsistent data access jumbled throughout, duplicate code, etc. The typical mess you see in corporate legacy systems.

Here's one from the olden DOS days... Way back when I first starting programming I was mostly writing MASM and C code at a company where most of the other development was QuickBASIC. Instead of using a decent text editor, they used the old BASICA interpreter to write code which required them to still use line numbers. It was painful to watch.

I was asked to debug a particular set of programs since my "terminate and stay resident" program was causing them to lock up. My boss berated my skills in front of the whole team, something every junior programmer on their first job enjoys. Here's what I found in a chunk of code that was duplicated about 5 times by the senior developer....

4000 REM Lookup Line Item
4010 GOTO 4000
4020 (call to my resident program here)

I once had a manager insist that we store thousands of mapping rules in XSLT. The incoming data was in XML. Of course, stored that way, the rules are useless unless your incoming data is in an expected XML format. The sane approach would be to convert incoming data to something more manageable and run the rules against that, so that a) if you ever get data in some other form you can also convert it to that same form and the rest still works, and b) you can test rules without having to create XML and XSLT.

Needless to say it broke constantly and was beyond impossible to maintain. That's what happens when you design something stupid and your plan to avoid failure is not making errors when you maintain a giant text file by hand.

I solved part of the problem by storing the rules in a database, writing code to convert the data to XSLT, and not telling her.

Flat file data storage, using VB6 string functions like indexOf to query because “strings are fast”.

I coded in a project which the last developer created a folder with a new index inside for each php pages in order to create friendly urls. thousands of pages in structured logic

That is weird, maybe they were using an old version of the ODBC jar. This would drive me crazy seeing something like this.