• Álvaro González (github)

    I'm not saying it's the case here, but that's how some of my early HTML looked like when you opened it with Windows notepad after years of editing it with multiple programs in different operating systems. I somehow managed to get Unix, Mac and Windows end of line characters, plus some others that technically don't exist.

  • kanade (unregistered)

    What’s uplevel?

    Not much, but don’t call me level.

  • (nodebb)

    I can remember twice where I was "reprimanded" (not really like that) for formatting the code because it showed up as changes in source control.

  • (nodebb) in reply to ObiWayneKenobi

    When I do that, I always indicate it in the comment:

    git commit -m 'reformatted --- NO CODE CHANGES'  foo.c bar.c
    
  • Jonathan (unregistered) in reply to kanade

    I came here to make the same joke. I don't know what that says about either of us.

  • Eddie (unregistered)

    This may improve test coverage when measure by line

  • (nodebb) in reply to ObiWayneKenobi

    It's annoying when someone makes a small change but also reformats the code, so it's hard to see the substantive change through all the formatting noise. Many diff programs can be told to ignore whitespace changes, but often this only means within and between lines, it doesn't ignore splitting or joining lines.

    Similarly, yesterday I was reviewing a change to a crontab. The programmer had replaced /home/username with ~username in all the paths, so there were changes on every line. There's no built-in way I know of to filter all those out. I could probably extract both versions, then canonicalized the paths in both versions and compared so I could see all the other changes.

  • (nodebb)

    There are a couple less-incompetent explanations:

    1. The code was generated with a template that didn't do line breaks correctly.
    2. Page_PreInit was added by a find/replace that didn't do line breaks correctly.
  • (nodebb) in reply to Álvaro González

    I somehow managed to get Unix, Mac and Windows end of line characters, plus some others that technically don't exist.

    I remember once getting a file to read where all the line endings were CRCRLF.

    But at least you don't have to deal with how MTS handled lines of text any more.

    MTS is/was an alternative (non-IBM, the M of MTS being (the University of) Michigan)) operating system for IBM System/360 and System/370 mainframes. Its native text format was a series of lines rather than a stream of bytes, and each line having length, content, and line number. And the line numbers could be fractional. (Line 1.000 being followed by 1.050 and then 1.340 and then 2.000, etc., with the stored value being "true line number times 1000" to let it easily be stored in an integer format.)

    Interesting to play with, but it must have been "fun" to map that to the "C" model of a stream of bytes. But it does explain why certain things are classed as UB when using FILE * libc calls (notably fseek() outside a sharply restricted set of things(1)) with text files.

    (1) If memory serves, the only non-UB combinations are (0, SEEK_SET), (0, SEEK_CUR) (causes the equivalent of fflush()), (0, SEEK_END), (x, SEEK_SET) where x is a value returned by ftell() for the same FILE *.

    Addendum 2026-09-16 10:52: It might have been CRLFLF instead of CRCRLF. It was 30 years ago, so cut me some slack.

  • (nodebb)

    I have a confession: I don't use autoformatters. I am very precise about how I like to format my code and it seems that most tools don't agree with me. However, I am so precise about how I format my code that I never let things like this happen. (In case it matters, I rarely work with others so it's easier to be opinionated without repercussions.)

  • (nodebb)

    I would like someone (looking at YOU, TDWTF readers) to write an autoformatter that arranges the code in a manner suitable for the Obfuscated C contest.

  • oh no (unregistered)

    That's nothing.

    At a previous job, the highly-paid-consultants would routinely check in lines of 512 chars. And copy/paste/paste/paste them, with a few characters changed on each paste.

    If they had to insert a few characters and ran over the 512 limit, you'd get a 512 line followed by a line with a couple tokens.

    Presumably, they would've had even longer lines, but the VS IDE limited them.

  • PotatoEngineer (unregistered) in reply to ObiWayneKenobi

    Once upon a time, in the days of yore, I was working on an app for dumbphones, because no phone was yet smart. The app was embedded in the phone, so both size and data usage were important. The app was made from a client, plus a pseudo-HTML "app" on top. In an attempt to cut down on the data usage, I tweaked the client's build to include the app. The client would download new files if anything changed, but otherwise, I was saving some data-usage by bundling the stuff it already needed.

    And then... for a moment... there was a new member added to the team, 8 time zones away. And he had problems getting the app to work (doing dev work on it was nontrivial). So, in an attempt to feel useful while unable to actually get anything done, he decided to format the "app" files, which were made with a variety of different text-editors and had terrible indentation. The files he "fixed" no longer matched the ones bundled with the client, and thus, we got the worst of both worlds: the client had to download new files and consume both extra data and extra storage.

    Had I been thinking, I would have reverted those changes when I found them, but I was young, and foolish, and uncertain, and I did nothing.

  • Ishura (unregistered)

    Page.ClientTarget = "uplevel"; was a real thing in old versions of .Net, and told it to treat the client as a "modern" browser. Without it, you didn't get some of the "advanced" functionality that we now take for granted.

  • (nodebb) in reply to cellocgw

    You mean something like starting by stripping all whitespace and then ensuring a maximum 37-character line length by splitting overlong lines on the operator with highest precedence?

  • FTB (unregistered) in reply to sudgy

    You: "I have a confession: I don't use autoformatters. "

    Yep. Manual code formatting can make code much neater, easier to read, and even reveal bugs.

    eg. This is on screen in front of me right now, I do NOT want an autoformatter to rewrite it.

    if (min_.x > max_.x) { std::swap(min_.x, max_.x); } if (min_.y > max_.y) { std::swap(min_.y, max_.y); } if (min_.z > max_.z) { std::swap(min_.z, max_.z); }

  • FTB (unregistered) in reply to FTB
    Comment held for moderation.
  • FTB (unregistered)
    Comment held for moderation.

Leave a comment on “Extremely One Line”

Log In or post as a guest

Replying to comment #704368:

« Return to Article