• (disco)

    *spotted a duplicate sentence (that will probably be gone by the time it's published)*

  • (disco) in reply to RaceProUK

    Wow, INB4 :hanzo:, just about to hit reply when this came in!

    Wait, what's a 💩.la supposed to be?

  • (disco) in reply to Tsaukpaetra

    Whatever it is, the domain doesn't resolve

  • (disco) in reply to RaceProUK

    Agreed. Should have stuck to plain ol' unicode characters. ¯(°_o)/¯

  • (disco)

    BRADLEY: It’s not new. It’s been in Java since 2.5…

    1.5

  • (disco)

    Hmm,

    • Programmer brought in to help a project
    • Programmer given clear specs on what to do
    • Programmer decides to do other stuff on top of this
    • Programmer told to only do exactly what is asked
    • Programmer given another task with clear simple specs
    • Programmer decides to change the API everyone else is using
    • I wonder who the dick is!
  • (disco) in reply to GettinSadda

    I don't know about you, but I want my programmers to be proactive and make sensible improvements where they are able; it's rare you get any significant period of time to clean up a codebase, so why not do it in parallel with everything else?

  • (disco)
    1. Open a connection. If an error results, return –1.
    2. Attempt to send the message. If an error results, return –2.
    3. Close connection.
    4. Open connection. If an error results, return –1.
    5. Retrieve response. If an error results, return –4.
    6. Close connection.
    7. Attempt to parse the XML response. If an error results, return –5.

    How is that suppose to work if you close and open another connection in step 3 and 4? Would you not get a different port?

  • (disco) in reply to Michael_Mahn
    Michael_Mahn:
    Would you not get a different port?
    Probably. Shouldn't matter though.
  • (disco) in reply to GettinSadda
    GettinSadda:
    I wonder who the dick is!

    Usually for each sprint in my code base I add a few items to clean up the technical debt that might have crept in along the way. In that way the Technical debt remains manageable and the code base doesn't get so bad I want to run away from it or rewrite it from scratch.

  • (disco)

    I was with Bradley up until the last part where he created a new exception type for each operation - WTF?

  • (disco) in reply to GettinSadda
    GettinSadda:
    I wonder who the dick is!
    RaceProUK:
    I *Sensible people* want programmers to be proactive and make sensible improvements where they are able; it's rare you get any significant period of time to clean up a codebase, so why not do it in parallel with everything else?

    FTFY. Refactoring should happen all the time. Especially after a rushed delivery, otherwise the technical debt accumulates and people like me who take pride in their work (admittedly not straightforward with javascript) and have a choice end up leaving.

    Tangentially, I have been told this:

    Do exactly as you're told, but also be proactive and independent.

    Obviously they told me in more words to try and obfuscate the flagrant output of :poop: from their talk-holes.

  • (disco) in reply to Tsaukpaetra
    Tsaukpaetra:
    ¯(°_o)/¯

    You dropped your right arm.

  • (disco) in reply to anonymous234

    I think a dischorse ate it, actually.

  • (disco) in reply to RaceProUK
    RaceProUK:
    I don't know about you, but I want my programmers to be proactive and make sensible improvements where they are able; it's rare you get any significant period of time to clean up a codebase, so why not do it in parallel with everything else?
    I agree in principle. But not on their own before clearing it with their PM or whoever is responsible for the project. Maybe there are more urgent things that need to be done if someone has free time?

    And yes, screwing around at will with functions you don't know and for which there are no unit tests just to make them look nicer is just asking for time bombs. BTDT.

  • (disco) in reply to RaceProUK
    RaceProUK:
    \*spotted a duplicate sentence (that will probably be gone by the time it's published)*
    No it ain't.
  • (disco) in reply to aliceif
    aliceif:
    I think a dischorse ate it, actually.

    ¯\_(ツ)_/¯

  • (disco)

    💩.la looks like a mojibake... python to the rescue:

    >>> "💩.la".encode('windows-1252').decode('utf-8')
'💩.la'
>>> _.encode('idna')
b'xn--ls8h.la
  • (disco) in reply to mata

    Ah, at least http://💩.la resolves :smile:

    ...and Discourse styles it as a link, but makes it unclickable. Yay.

  • (disco)

    “WHAT?” Bradley asked his monitor. The methods all threw Exception, with no customized type. He could still trap the errors and map them to the integer error codes requested, but it made for a lot more work. This time, he figured improving the codebase was in line with the spec:

    So, he failed to follow the requirements, he changed the code willy-nilly without knowing how it's externally used, and all that because I want to write good code, dammit!?

    Look mate, we all do, we all do, but the reason why it's so hard is that you really can't just fix stuff that's used elsewhere as you go along.

  • (disco)

    Only the instant messenger’s lack of emoji support saved Bradley’s job.

    That and the lack of being able to stab people in the face across the Internet.

  • (disco) in reply to powerlord
    powerlord:
    That and the lack of being able to stab people in the face across the Internet.
    It's only a matter of time...
  • (disco)

    Javatechsoft Industries had backed themselves into the classic testing trap: it was too risky to make changes, because they had no automated tests, but the only way to get automated test was to make changes.

    That's basically been every single development job I've ever had. Never time to go back and refactor code to allow for testing so it can be easily changed, just bang out new features and push everything else to the backburner. I was actually let go from a job (you might recall it being featured in the Shadow Over Shippoint Halloween story) because I kept reminding the CTO (who always told me that he wanted to have a good codebase that allowed for easy changes) about how we really needed to invest time in code cleanup and getting tests running instead of doing silly things like redoing the HTML for a page because it looked better on the iPad, despite none of our customers using iPads.

  • (disco) in reply to Shoreline
    Shoreline:
    Do exactly as you're told, but also be proactive and independent.
    Translation out of management-speak: 1. If you make a change and something goes wrong, it's your fault, because you didn't do exactly as you were told. 2. If you don't make a change and something goes wrong, it's your fault, because you weren't proactive and independent.

    Bill doesn't seem to be blaming Bradley for stuff though - what he's actually doing is using his organizational power to protect his own code from modication, because like all not-good programmers he believes his own code is perfect whereas everyone else's code sucks. Good programmers know better - their own code sucks too!

  • (disco) in reply to ChrisH

    And yes, screwing around at will with functions you don't know and for which there are no unit tests just to make them look nicer is just asking for time bombs. BTDT.

    Actually IIUC if those specific error classes inherit from Error, then all the existing code that catches generic Errors thrown would still work, as per inheritance.

    On the other hand thing how much fragile code one would have to write without this change.

  • (disco)

    So.... he did that just so he could do all the things in a single try and write 4 catch blocks for each type of exception, instead of writing 5 try...catch blocks so every thing could be in a different one?

    I'm not sure that's significantly easier.

    edit: what does it return if closeConnection throws an exception? Does the application just crash and burn?

  • (disco) in reply to anotherusername

    It may not be that much easier, but it's definitely more maintainable; the actual implementation is in one block instead of being split up by all those catchs.

  • (disco)

    "Drive by Coding" is a major problem (developers making changes that are not specifically required to meet the spec)

    "Rotten Code" is a major problem that needs to be addressed, or the application WILL collapse over time.

    Apparent conflict.

    BUT, if the developer simply logs (they are using a work tracking system that is integrated with their defect management system, right :wink: ) each code issue so that it can be scheduled for review and remediation, things tend to get a lot better (though it takes time).

  • (disco) in reply to RaceProUK

    Well, if you really wanted to do it in one block, you could... just use a variable to hold the return value and set it before each operation that might fail. In the catch you just return whatever value that held, because it tells you how far the code got.

  • (disco) in reply to anotherusername

    Yes, old style exception handling. This is exactly what I think was expected.

  • (disco) in reply to RaceProUK

    So that would make an interesting coding challenge. Some initial thoughts:

    1. Get them to remove the back cover of their CRT and sit there while you send them the codez to make it implode, sending sharp slivers of glass in every direction.

    2. Mechanical Turk. 'Nuff said.

  • (disco) in reply to TheCPUWizard
    TheCPUWizard:
    BUT, if the developer simply logs (they are using a work tracking system that is integrated with their defect management system, right ) each code issue so that it can be scheduled for review and remediation, things tend to get a lot betterhard drive space tends to get clogged with code issue log files (though it takes time).

    FTFY

  • (disco) in reply to TheCPUWizard

    That's assuming that it ever gets addressed. In my experience most of the time it doesn't matter if you track the issues or not, it will never ever be scheduled for "review and remediation" because whoever decides that sees no value in fixing what "already works", no matter how shitty/busted it really is.

  • (disco) in reply to DocMonster

    About a third of the stuff this site thrives on is due to exactly this.

    Btw, anyone here who doesn't experience that?

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    without knowing how it's externally used

    True, but wherever it's used, they're catching Exception anyways so it doesn't really matter. They'll still catch it (assuming he's extending Exception) and it will work fine.

    EDIT: The only change it might make is to give slightly more useful stack traces. Of course with a company like this, they might be doing the

    catch(Exception e)
{
    System.out.println("Error!")
    throw e;
}

    anti-pattern

  • (disco)

    Practically every single article on this site ought to end with the protagonist asking: "Why the fuck did you hire me, if you didn't actually want someone who knows what they're doing?"

  • (disco) in reply to sloosecannon
    sloosecannon:
    True, but wherever it's used, they're catching Exception anyways so it doesn't really matter.

    Then it gets logged together with its runtime type, and whoops, you no longer have a java.lang.Exception (or whatever Java does there) written into the log, so the job that parses the log file with a regex and sends an email to the developers misses the error, so the devs never learn that their service is crashing until a billion-dollar customer breaks a contract.

    I mean, likely nothing would happen and everything would work. But the "no changes to the API until you're 100% sure nothing breaks" is there for a reason.

  • (disco) in reply to RaceProUK

    I hear modern computers have a builtin math professor. Maybe we can entice them to do the stabbing?

  • (disco) in reply to Maciejasjmj

    That's true. External connections could be an issue (But if they are doing something like that, that's so stupid... it... I don't even...)

    Throwing Exception is probably the stupidest anti-pattern possible though......

  • (disco) in reply to sloosecannon
    sloosecannon:
    Throwing Exception is probably the stupidest anti-pattern possible though......

    Well, yeah, nobody really argues it's not stupid. But you'll find this kind of stupid shit in every codebase - sometimes it will be the small things like throwing an Exception, sometimes bigger like consistently doing your SQL queries in button click handlers. And I know firsthand how tempting it is to just rewrite this shit altogether, but usually that's not what your time is supposed to be spent on, it can break things, and it leads very quickly to the CADT development model.

  • (disco) in reply to PWolff

    Actually I don't, but I guess I'm in that lucky situation that I decide what needs to be fixed / added and when. (Ok the downside is that I'm also the one which gets the blame if something doesn't work or a change breaks something, but you can't have your cake and eat it too...).

    Yazeran.

  • (disco) in reply to Maciejasjmj

    But if they are anyway not using exceptions and negatives return values for error handling instead ...

  • (disco) in reply to Maciejasjmj
    Maciejasjmj:
    Then it gets logged together with its runtime type, and whoops, you no longer have a java.lang.Exception (or whatever Java does there) written into the log, so the job that parses the log file with a regex and sends an email to the developers misses the error, so the devs never learn that their service is crashing until a billion-dollar customer breaks a contract.

    WHAT!? Surely no customer would try parsing the undocumented debug messages out of the syslog! And they certainly wouldn't then complain when those same undocumented and unguaranteed messages change from release to release...!

    Nope, can't do it. I can't even type that with a straight face.

  • (disco) in reply to Eldelshell
    Eldelshell:
    > BRADLEY: It’s not new. It’s been in Java since 2.5…

    1.5

    Isn't JDK 1.5 Java 5?

  • (disco) in reply to FrostCat

    I'm always confused by that too.

  • (disco) in reply to Maciejasjmj

    I'm not familiar with Java. Would anyone actually notice if you create new exception classes that derive from Exception? At least in C++, if I throw MyException, derived from std::exception, anyone can catch it as a std::exception. If they were already catching as std::exception in the first place, the change wouldn't affect them.

  • (disco) in reply to Kian

    Remember: the objection was from a guy who freaked out about removing unused imports.

  • (disco) in reply to Kian

    Catch, yes. Any other reflection (or RTTI, in C++-lingo) tricks, and you're knee deep in the mud.

    And there's still the whole time management thing. Even if the change is functionally a no-op, it still requires resources to make it, process it and run a regression suite (automated if you're lucky) against it. Resources you might or might not have.

    Yep, cleaning up the code feels nice, but ultimately it's all about features and bugs, and sometimes taking the technical debt now is what you have to do.

  • (disco) in reply to Kian

    In Java, everything that you can throw and catch is derived ultimately from Exception (stuff you throw but don't catch is derived ultimately from Error). So if you have class Supercalifragilisticexpialidoception extends Exception, catch (Exception ex) will catch it.

    Plus the stuff :fa_arrow_up: above.

  • (disco) in reply to FrostCat

    Yes. There's never been a Java 2.5. It went 1.0, 1.1, 1.2, 1.3, 1.4, 5, 6, 7, 8

Leave a comment on “No Changes Please”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article