Reminds me of a comment I once came across in a work application’s code: “This function took forever to write correctly. It was hard work. I didn’t document it. Figure it out.”
Of course the variables were not defined properly and were named esoterically.
the variables were not defined properly and were named esoterically
I wonder why it was so hard and took so long to write
Poor skill, mostly.
As demonstrated by the variable naming and documentation.
Oof!
deleted by creator
At what point is documenting decompiled code easier?
Me: “haha…no” proceeds to delete function “whoever wrote this can figure it out again.”
$ mysterytool $WHAT DID YOU DO?!
$ mysterytool -vv DEBUG: Complete. $Knowing my luck, It probably deleted a rarely used system library and will lead to unpredictable crashes.
I don’t understand how devs can be too lazy to write documentation but somehow they’d rather explain the same shit in discord over and over and over and over and over and over
The help command is one of the first things I work on in any project. Even if I’m never gonna share it, my future self will appreciate it.
Even on simple scripts, it’s so help to remind yourself however the hell you made it work.
I always document a lot because I forget what I was doing one week after.
Removed by mod
Why?
i write poorly documented code on my solo projects because i am lonely
I write buggy software so that users will email me.
I think it’s loneliness, honestly.
That and corporate work environment tends to rewards those that can explain stuff vocally ad nauseum.
As someone who writes fairly extensive documentation, I can assure you that it doesn’t matter. People will still ask questions in your Discord that are answered in your documentation.
I’ve learned that you kind of have to strike a balance between being terse enough that people will read it and verbose enough that it’s actually helpful, but there is a minimum number of questions you will always get.
At work, I am one of the few who actually documents. Not only with Doxygen, but I also write real documents regarding all kinds of topics.
Guess what? “I know you have this documented somewhere, but could you just quickly explain again how this common task works?”
I was recently trying trying to get help on a clipboard program someone had recommended me, clipq. What I found instead was a GitHub discussion where the dev said “I’m not sure what you mean by ‘man’ pages” in response to someone asking for them. I think I need to find an alternative
Did they at least provide woman pages then?
/s
I’ve only known about (and always use) xclip.
copyq — if anyone needs universal multiplatfom gui app
Be the change you want to see in the world and create a PR. 😃
tbf syntax for writing manpages is closer to latex than markdown
It is not that complicated and there are plenty of tools to generate man pages from other formats. Besides, this is about the dev not knowing what a man page even is.
Stuff like this is why I’m really glad I was a hard ass about learning “the right way,” and refused to let myself use a full IDE and instead rely on a terminal setup. Crazy how many people (with tons of experience) can be missing basic knowledge about how *nix environments run
I can’t imagine working with linux and not being comfortable with its most fundamental conceit: interactive ttys that you can do anything from. It’s like being a Windows user and not knowing about the Start menu
Soy devs have invaded Linux.
What do you mean by this?
“You’re not a real dev if don’t know [insert thing here]”
I’m not seeing the soy connection
It’s a derivative of https://en.wikipedia.org/wiki/Soy_boy
Haha, I made this :) Here’s the blog post I created it for, if you want a bit of context:
Correct, I shamelessly stole it!
Also, sorry, I stole it.
No worries :)
But also
mysterytool --help
mysterytool: unrecognized option: '-'ok then…
mysterytool -h
mysterytool: unrecognized option: 'h'mysterytool --help ‘--help’ unrecognized option, -h for helpI will burn this motherfucker to the ground
Or the opposite:
mysterytool -h -h unrecognized option, --help for helpBoth need to burn.
Sometimes
mysterytool -Hworksmysterytool -haaaaaalpSome of the older programs and scripts I’ve seen in the codebases I help maintain have
-uor-?. If I have an excuse to do any changes to them I’ll usually change them to use-hand--help.
And
mysterytool -hmysterytool: try our info page that requires a custom viewer because gnu is better than standards. And there is no regular man page because fuck youIf I can’t get it with
tldr mysterytoolafter all that, then clearly the developer intended it to stay a mystery.strings mysterytoolAs a last resort haha
It could be worse. The documentation could be online, only accessible through a paywall.
Okay, Oracle.
Oh, they do it, too?
Programmers generally detest to do documentation, so when the user help “UI” is all down to a programmer to define this is often what you get, especially if it’s a small tool.
I never understood that. I’m a programmer and I tend to over-document.
Yeah this is shitty, and if you’re a programmer reading this and you agree with it, be better. There is no excuse for under-documenting a CLI.
Even when I’m developing, I write out my usage text first, like
-o [json,csv,pretty] specify output format (default 'pretty') [NOT IMPLEMENTED]or the like.Speaking for myself a long time ago when I was younger and handsomer but dumber ;) some people at a certain stage of their lives have trouble remembering that what’s obvious for oneself given the context one is in and the information one has, is not obvious for others.
I like to think most of us grow out of it.
I like to think most of us grow out of it.
Morgan Freeman: “But they didn’t”
If you use something like Rust’s clap --help output is very easy to add, all you need is basically a single line comment for each option.
Oh, you sweet summer child, there is no level of ease for the average programmer that will make him or her want to document things… ;)
On a more serious note, good documentation for parameters in any tool that’s not stupidly simple tends to be more than a one liner if one doesn’t assume that the user already knows a ton of context (for example, imagine explaining “chmod” parameters with just one liners)
You can write more than one line but one line is usually enough for each of the options in the --help output. Obviously that doesn’t explain everything and especially not background like “how do unix permissions work” in your example but the --help output is not the correct place for that kind of information anyway.
The point is that a programmer would first need to think about what needs to be explained or not to the average user and then explain it properly, none of which is considered as interesting as coding.
It’s not by chance that even tools with actual one line of explanation for each parameter are general of the badly documented kind (I especially like the ones were the “help” for a command doesn’t say what the bloody command actually does).
I mean, you even see this kind of meaningless “documentation” in API documentation for widelly used libraries were the documentations is generated from comments embedded in the code: “public void doStuff(int height)” => “Does stuff. Parameters - height: the input height”.
I might have put it in a humouristic way but this quite a well-known and widespread phenomenon.
No idea why’d anyone would do this if they expected anyone besides them to use their tool.
Even I myself am not gonna remember how to use my tool a couple months down the line, unless it’s something I use very regularly.
Edit: noticed I read the comment I’m replying to wrong, reworded to make more sense
Embedded *nix be like
Cries in busybox
That, at least, had an excuse to be terse. If you use busybox, you probably have a real machine with the ability to browse the online documentation, anyway.
Legacy *nix vendor tools be like
It’s like people don’t like surprises anymore.
strings `which mysterytool` | lessGive up your darn secrets before I start fumbling around with
straceand get even more frustrated!Exclusively installed through some dodgy PPA you got from a blog.
I just want to say this is a masterful use of the format.
I’d try
mysterytool -H-H for Hard drive to delete, -h is help
-H is for Hforce
-his halt.Which assumes you also wanted to catch fire because you didn’t set
--halt-without-catching-fireDo developers get hard-ons for using nonstandard flags?
Use
-h, --help. None of this “no hyphen” bullshit or using the plus sign or a different flag like--infosudo shutdown -h nowIt makes sense in context. Whaddya gonna do?
-His for “hell no just uninstall”Look, if they can’t stick to established convention and they’re not gnu (and thus magically excusably arrogant as fuck because #stallman), then you just know they’ll be somehow dragging in remote libraries or something equally as fuckwitted; so just remove it and live your life.
find / -name mysterytool -exec rm {} \;rm $(which mysterytool)?What if that returns just an alias?
But really the best way would be first to try one’s distro manager to uninstall/purge the package. Unless it was just manually installed by the user.
Oh, maybe that’s it! It only exists in
~/bin, and OP is having a psychotic break, is just now finding out about their split personality!
Use
+;\;is for peasants.Y u no
-delete
Quite the mystery!
