Ask HN: Does anyone still use code snippets?
I noticed that I still like them and rely on them and was wondering if that’s the same for someone else.
I noticed that I still like them and rely on them and was wondering if that’s the same for someone else.
1. When loading an empty file it inserts boiler-plate based on mode (largely that is based on the filename suffix). So if I open a buffer "t.pl" it will insert "#!/usr/bin/perl", along with "use strict; use warnings;", etc.
2. Completion for LSP-modes via yasnippet. So in golang mode I type "iferr[TAB]" and it expands into "if err != .." and moves my cursor to the proper spot when I type TAB.
Around 85% of the time, it seems like it takes me more time to write what I want to code in natural language to an AI prompt (and then correct it) than it would to actually code what I want.
The 15% of the time when I want something like "Write test cases to cover this module" is something a snippet couldn't do anyway.
That's how it should be, actually 100%. If you need scaffolding (and snippets) it means your language doesn't have (or worse, can't have) the right abstractions in its library.
- the use cases covered by the language could be so varied that it would be misguided to expect special functions for each of those cases
- what one programmer describes as scaffolding could be seen as essential part of the setup for others. I have seen essential parts been called "scaffolding" by beginners who had no idea this was not just "text that needs to be there", but it had implications for the whole thing.
https://en.wikipedia.org/wiki/Scaffold_(programming)
Nothing about scaffolding pertains to how important it is.
Eg. most languages would enable you to build a custom library, but then it becomes non-obvious what's exactly happening to someone diving into the project, a most engineers never bother fixing/improving the original library, and you end up with crap on top to "work-around" the poorly understood behaviour.
Eg. recently, I've fixed an internal library holding multiple locks around one tiny block of async code, rendering the entire thing synchronous, which was being worked around by devs using multiprocessing or multithreading for a couple years. I've reduced that library code to basically a couple of functions, but my preference would be to actually copy-paste those 200 lines into every component using it — while you have the problem when you want to update it everywhere, your average engineer focused on solving a different business problem will be better equipped to handle it.
My personal gripe is with the abuse of @decorators in Python, which are side-effect pits of hell (yes, the code can look really nice).
I personally don't use snippets, but I do copy-paste some of that scaffolding between projects (though I am mostly a manager these days and hardly get any time to code, so take that with a huge grain of salt) — snippets as such never added much value to me.
But solving that tooling issue is hard (or we'd have a great solution already), and we choose our compromises based on the reality we live in. Neither is perfect, and we should continue thinking how we can improve the situation from all angles, including improving the tooling as you suggest.
And just as I posted this, an articles shows up on the front page (https://www.dbos.dev/blog/what-is-lightweight-durable-execut...) claiming this:
> So how does this work? The key is in those decorators, DBOS.workflow() and DBOS.step(). They wrap your functions with the code that durably executes them. At a high level, they persist your program’s execution state–which workflows are currently executing and which steps they’ve completed–in a Postgres database.
Ouch! Those innocent looking lines of @DBOS.workflow or @DBOS.step make decorated functions actually connect to a Postgres database somewhere, and you can't be certain if you can test those functions without Postgres anymore. Ouch, ouch, ouch!
So, developers, please, remember the implicit vs explicit rule of thumb.
My issue with the code they generate is mostly that the style of abstractions chosen is inconsistent and seems to replicate whatever was the source at any given point. Programming is still about understanding what is going on, not about just writing code, so either way you need to put in the brainwork to understand it.
But as a "just show me an example"-helper it can save you a lot of time, especially if you load highly undocumented and convoluted codebases into it.
In some cases I had the LLM hallucinate functions that would have been wonderful if they existed, but hey.
- You can just type a CSS selector (actually a superset of CSS), then expand it into the analogous HTML.
- In VS code if you select some HTML then hit ALT-W, you can enter an Emmet snippet that surrounds that HTML.
Examples: https://docs.emmet.io/cheat-sheet/
When I am working on new stuff... Well, my typing is mostly on autopilot, I use the time to think about what I'm going to put next, or else I've reached a spot where I would be making decisions anyway, e.g. naming a method.
`af` expands to `() => `
`naf` expands to `export const foobar = () => {};`
The expanded snippets can be tabbed through as well
It feels like a big timesaver
I also use the nest cli to create new modules, services, ... which are king of snippets also.
I think a lot of the standard snippets from years past were already taken over by things like IntelliSense, or various other IDE plugins.
note - gh:
> [!NOTE] > Highlights information that users should take into account, even when skimming.
ruby - html:
<ruby>WORD<rp>(</rp><rt>CAPTION</rt><rp>)</rp></ruby>
This is a result of a process I call experience distillation. I notice what code I write often but tend to either forget (bash) or outthink much faster than I can type (common syntax, libs, boilerplate), and routinely add it to snippets in hope that it sticks. Then I learn to actually use it. Once in a while I delete the unused or reshape it for second attempt with the understanding why it failed the first time.
Copilot have not been able to generate arrow functions when I intend to, in my experience. I found it pretty incompetent, and unable to provide relevant assistance if there is any bit of abstraction. YMMV.
I reckon my need for this specific snippet could be replaced with a more competent agent. I recently subscribed to cursor and so far it seems promising.
you have a snippet for four characters? `()=>`?
That’s not to say that “AI” assisted coding isn’t useful -in fact it can be indispensable. For me, the value is mostly it being a seemingly perpetually slightly drunk, yet prescriptive, pair coding partner.
I have some configured to enter the names of colleagues I've paired with to commit messages in the format GitHub expects too.
When doing some quick experiment in C/C++, scaffolding `int main ...` and classes is nice too.
In nicer languages I use snippets only if I forget syntax, than snippet serve as a quick reminder(e.g. for loop in lua)
If I ever do use llms it's for searching for something like "what kind of expression is this called: (i = 0; I < x; i++)" so that I can do better research myself.
No clue if it's true, but this is why I assumed a lot of older computing stuff is often abbreviated to the point of obfuscation.
You can always copy-paste from nearby code that also calls it.
I don't autocomplete everything, as picking things from a list is if not slower then at least more annoying than just typing that thing, but for common things it's helpful. For instance I type "game.ReplicatedStorage" all the time, so taking a few moments to learn that "game.reso<tab>" is the same has saved time.
What upped my motivation to learned some shortcuts was switching from one keyboard layout to another (qwerty->colemak) and having 20-30 WPM for a week. Typing everything was so painful that I could doubly appreciate it.
Additionally, AI doesn't know how to produce the same output on each execution.
The rest I can just do with whatever AI I'm currently using, they'll usually guess the variables right the first time too.
With AI, you never know what you'll get. OTOH snippets were created by hand by me. I know what to expect of them and what not to expect. They are always the same.
we dont use AI at my work