> I believe that most engineers want to write good code

But the opinion what makes code good differ a lot between software developers. This exactly leads to many of the inconsistencies in the code.

And that’s why you talk about it and agree on stuff. I call that being a professional.

Exactly this. I (relatively recently) joined a team with a handful of developers all sort of doing things their own way. No docs, no shared practices, just individuals doing their own thing. After reviewing the code, submitted PRs with fixes, putting together docs for best practices, the entire team shifted their stance and started working closer together in terms of dev practices, coding styles, etc.

Not to say I got everyone to march to my drum -- the "best practices" was a shared effort. As you said, sometimes it just takes someone to call things out. We can do things better. Look at how things improve if you approach X problem in Y manner, or share Z code this way. Maybe the team was overwhelmed before and another voice is enough to tip the scales. If you don't try, you'll never know.

doing some recent contract work I discovered someone putting this into a PR (comments my own)

```

let susJsonString = '...' // we get this parseable json string from somwhere but of course it might not be parseable. so testing seems warranted...

try { // lets bust out a while loop!

while(typeof susJsonString === 'string') { susJsonString = JSON.parse(susJsonString) }

} catch { susJsonString = {} }

// also this was a typescript codebase but all the more reason to have a variable switch types! this dev undoubtedly puts typescript at the top of their resume

```

I suppose this works?! I haven't thought it through carefully, it's just deciding to put your shoes on backward, and open doors while standing on your head. But I decided to just keep out of it, not get involved in the politics. I guess this is what getting old is like seriously you just see younger people doing stuff that makes your jaw drop from the stupidity (or maybe its just me) but you can't say anything because reasons. Copilot, ai assisted coding only further muddies the waters imo.

This is totally fine. If you're given shit data this seems like a reasonable way to try to parse it (I would personally bound the loop).

Typescript is not going to make it better.

The problem is whoever is producing the data.

I think the complaint here is they have a string, which even has the word string in the variable name, and they turn it into an object at the end. Hence references to Typescript.

I suppose what is wanted is something like

let parsedJSON = {}

try { parsedJSON = JSON.parse(susJsonString) } catch { //maybe register problem with parsing. }

That's quite different though. It looks to be dealing with the case that a serialised object gets serialiased multiple times before it reaches that point of code, so it needs to keep deserialising until it gets a real object. E.g:

    JSON.parse(JSON.parse("\"{foo: 1}\""))

I'd guess the problem is something upstream.

Hmm, yeah ok, didn't pick this out of the

let susJsonString = '...'

example

but evidently it is not just that it is serialized multiple times, otherwise it shouldn't need the try catch (of course one problem with online discussion of code examples is you must always assume, contra obvious errors, that the code actually needs what it has)

Something upstream, sure, but often not something "fixable" either, given third parties and organizational headaches some places are prone to.

Yeah. I imagine that's a bandaid around having to consume a dodgy api that they didn't have access/permission to fix.

The blanket catch is odd though, as I'd have thought that it would still be outputting valid json (even if it has been serialized multiple times), and if you're getting invalid json you probably want to know about that.

probably some times the api comes out with an empty string.

Putting this in my web console:

  let susJsonString=JSON.stringify(JSON.stringify(JSON.stringify({foo:1})))
  console.log("initial:", susJsonString);
  try { 
    while(typeof susJsonString==='string') {
        susJsonString = JSON.parse(susJsonString);
        console.log("iteration:", typeof susJsonString, susJsonString);
    }
  } catch {
    susJsonString = {};
  }

I see:

  initial: "\"{\\\"foo\\\":1}\""
  iteration: string "{\"foo\":1}"
  iteration: string {"foo":1}
  iteration: object {foo: 1}

A comment explaining the sort of "sus" input it was designed to cope with may have been helpful.

It will stop when it gets something that's not a string due to

    while(typeof susJsonString==='string') {
        susJsonString = JSON.parse(susJsonString);

as it'll keep reassigning and parsing until gets a non string back (or alternatively error out if the string is not valid json)

Now two of you are misunderstanding.

It’s applying the operation recursively.

Why the while loop

Because some upstream idiot is calling JSON.stringify several times.

I've seen this happen when someone's not familiar with their api framework and instead of returning an object for the framework to serialize, they serialize it on their own and return a string. Which then gets serialized again by the framework.

You came in so confident it was wrong, but it turns out you don’t really know what it does.

Please take a lesson from this. Good code is not the one that follows all the rules you read online. Your coworker you dismissed understood the problem.

I didn't know that JSON.stringify could be called multiple times on the same object and then unpacked via repeated calls to JSON.parse. So I was wrong on that. I think definitely this warrants a comment in the code, at the least explaining why this was taking place. The likely reason for the nesting was I think calling an LLM for a valid json object and somewhere in that workflow the json object was getting stringified more than once. I suspect this is the fault of the codebase and not the LLM itself, but it was typical of these devs to not ever investigate the api to understand what it was returning and rather just apply bandaid after bandaid.

I reserve my general opinion on the quality of this coder's work, as evidenced by the quality of the app itself among other things. But I guess you'd have to just trust (or not trust) me on that.

So no lessons learned?

Did you reply to the wrong comment?

I think asking questions is ideal. Even when I'm 99% sure a line is blatantly wrong, I will ask something like, "What is this for?". Maybe I missed something - wouldn't be the first time.

Darepublic originally posted his coworker’s code to make fun of above.

Sure, but that does not imply they will follow whatever you found out to be the best for the piece of code you are working on right now.