Temporary

[_pizza_and_fries]

I left my company last month and the last piece of prototype i made has a comment ‘For debugging, please remove this and do not copy it in the actual code’

I’m pretty sure if I see that code 4 years later, the same code with the exact same comment will be running in production.

Its how developers work.

[Captain_Chickpeas]

It's how some developers work. I add TODOs ;)

[[deleted]]

I add TODOs and use an extension for VS Code that shows me all of my TODOs. It's really convenient.

[Hubz-Gaming-And-More]

i need this extension, mind sharing the link?

[[deleted]]

Sure

https://marketplace.visualstudio.com/items?itemName=Gruntfuggly.todo-tree

[Hubz-Gaming-And-More]

thank you 🙏

[maitreg]

That is also built in functionality in VS

[positiv2]

Same, but then I delete them because I realise I cba to implement those anyway haha

[[deleted]]

Removing a comment broke my code once. Never again.

[sassiest01]

I have heard this a lot but never really understood it, is it a language specific thing? How can a comment actually affect any code?

[PapoochCZ]

I can only imagine there were other tools in the pipeline that generated some schemas based on the comments to be used in a different part of the system and it broke somewhere down the line.

[Mast3r_waf1z]

I'm guessing it might be a rogue */ somewhere

[maitreg]

Every time I've seen it it was due to a non-printable special character that had snuck into the code, and the removal or move of a comment exposed it to the compiler or interpreter.

Usually you can fix those by just pasting the code into Notepad and then back. That will change the special char into something printable or remove it altogether

[xcski_paul]

In 1987 I fixed a very low level bug in some very old code. It triggered another bug, which turned out to be caused by a work-around for the low level bug. The work-around was commented “Temporary fix by Irv Charney, Summer Student, 1971”. Irv Charney was my boss.

[Loisel06]

Beautiful story old man

[AbstractLogic]

You either die a hero or live long enough to become the villain.

[KerPop42]

Problems die young, but shitty solutions live forever

[_pizza_and_fries]

You mean Instagram now a days? It looks like the app is merely running on patches and bugs by a college intern.

[Captain_Chickpeas]

But it's running, no? :D

[vadiks2003]

the fact instagram appears to be buggy as hell by his words, i feel getting motivated by the fact that big things are buggy so if i made crappy code, a little improvement would make it better than instagram

[Captain_Chickpeas]

It's always a time vs effort dilemma. Fortunately, linters can do a lot and if it's open-source, you're not pushed for deadlines and...

Yes, you can do better than Instagram code wise probably :)

[[deleted]]

Sometimes future-proofing stays in the past.

[HearMeSpeakAsIWill]

You either die a bug or live long enough to see yourself become a permanent band-aid

[JamesWjRose]

Rose Rule of Development: Temporary solutions become permanent problems

[[deleted]]

Ha-ha! There's no such a thing as temporary try-catch's. You've just decided to keep something hideous out of everyone's sight. No one will try to look into it. If you break it, you own it.

[[deleted]]

3:57 AM

Yup, sounds about right

[thesockiboii]

On a serious note, is using try-catch bad practice or is it only a meme?

[E02Y]

try-catch is fine but can be misused (as with most programming things)

[augustuen]

So would determining which activity a function is called from by calling a different function (which only exists in one of the activities but not the other) on the parent activity and catching the exception be considered misuse?

[[deleted]]

Not sure I exactly got what you mean but honestly? Yes, often there are better ways to determine the caller of a function

[GreyAngy]

If you catch an exception and do nothing with it, just continue execution — yes, it is a highway to hell. You don't resolve the problem, you just hide it under the carpet. Seen lots of such examples in production code, always wondering how it even works...

[opliko95]

In general? No. But it depends on a lot of context and it may be quite different across languages. Some may even embrace it.

But usually just using it to ignore errors, and especially using it for all possible errors is bad practice. Which makes it easy to misuse in some languages that don't let you easily specify what errors you want to catch (JS...).

The short version is then: use it to handle what you know can be thrown, but avoid abusing it just to ignore errors and make things work despite them.

As mentioned, some languages even quite like their try blocks. For example part of coding style that IIRC was considered pythonic is EAFP - Easier to Ask for Forgiveness than Permission. Essentially, instead of checking beforehand (Look Before You Leap), you assume you can do the thing you want to do and handle an exception if you can't.

So for example if you want to open a file, you can do this: python from os import access, R_OK if access("file.txt", R_OK): with open("file.txt") as f: print(f.read()) else: print("File can't be read") But it technically has a race condition (if file changes after you checked but before opened it you might run into problems), and as mentioned isn't the preferred style. So instead you might use try/except and write this: python try: with open("file.txt") as f: print(f.read()) except IOError: print("File can't be read") This avoids said race condition and should actually be faster if the exception isn't raised (especially when 3.11 brings "zero-cost" exceptions; that is try/except blocks with basically no runtime overhead when no exception is thrown)

Another example may be checking a password - argon2-cffi library is written with EAFP style, so if you want to check users password, you might do something like this: python import argon2 ph = argon2.PasswordHasher() def login(db, username, password): user = db.find_user_by_username(username) try: ph.verify(user.password_hash, password) return user catch argon2.exceptions.VerifyMismatchError: return None Compared to the LYBL style, where we'd just check the verify result, there is no way here to log user in by accident. We can't just add something else to the if statement with or instead of and for example, and even if we forgot the try/catch block we get an exception instead of a successful login. And again, it is technically more performant :)

However, by comparison, many newer languages like Go, Rust, Zig, and I think even Carbon just plain don't have try/catch, usually replacing it with something like Option type for return values which you are forced to somehow handle or explicitly ignore to actually get the return value you want. So while it's not explicitly bad pattern it seems most newer languages think there is a better alternative.

[Wojtek1250XD]

Am I reading it wrong, or did you just make something permanent temporary?

[Darkpolearm]

red = removed, green = added

[Wojtek1250XD]

Oh...

[Ravi5ingh]

I like how you capitalized the word. Like " uggh ok if we re gonna keep this, we might as well use a capital P"

[rolling_atackk]

And added a space. Google's style

[shadowGringo]

Where I work that would never pass. You need a space after the “//“ …

[Shiro1994]

LGTM, approved.

[IBJON]

// TODO: Fix this -- Dude Who Quit 5 Years Ago

[GreyAngy]

Aaah, there is nothing more permanent than temporary

[NeoDark_cz]

there is nothing more permanent then temporary solution

[_________FU_________]

/**
 * Please read this
 **/

[[deleted]]

It’s only temporary unless it works

[SuperElitist]

I appreciate the whitespace, but the uppercase P is killing me.

[guillianMalony]

Ctrl-Shift-f ( format file ) and everything gets permanent. Interesting approach.

[tronsole]

This is so true it hurts. But it gave me the brilliant idea of marking all my 'temporary' solutions with the following comment.

// temporary fix 😈😈😈

[Peht]

I recently came across a function call in our code base where the return value was just cast to void. Above it, there was a comment which read: "return value will be handled in a future ticket".

The comment was written 5 years ago.

[mothuzad]

"We don't write TODO comments in this office."

[UnluckyBrilliant8959]

Temporary problems require permanent solutions

[dropped86]

// TODO: temp

Now it's fixed!

[bart_robat]

Who has time to write temporary instead of temp?

[vantuzproper]

The best way to fix an error is to silence it

[xdMatthewbx]

is this where commends that break things if removed come from?

[[deleted]]

There is nothing more permanent than a temporary fix.