-
Notifications
You must be signed in to change notification settings - Fork 646
Snippet improvement suggestions #1920
Comments
For the The second case is supported in a way already. After declaring the type |
I'd be happy to accept a PR for the first issue.
|
Aha! I totally did not see that at all, thanks.
${2:}err is more convenient because 99% of the time you either want to return just the error, or return the error and add more return parameters (unless using goreturns). If ${2:err} is used and you want to add more return values you either have to overwrite "err" with them all, or cancel the snippet to prepend them.
Okay, I will take a look 👍 |
Ah, understood. |
Also, feel free to go through the other snippets in that file, to see if they can be improved |
Hello,
First off, let me just say that coming from Sublime Text, I am loving vscode and vscode-go. They're clean, functional, maintained, professional products.
I have a couple of suggestions for snippets which I think would improve the common use case, based on similar functionality in GoSublime:
For "iferr", it seems like the 99% common case is to "return err", but the snippet does not have this and instead highlights "return" for replacement. I found the following to be much more convenient:
A set of "method" snippets could be dynamically generated from the existing types in the package. That is, if a type
type Foo <...>
exists, dynamically add a snippet of the formfunc (f *Foo) ${1:method}(${2}) ${3} { ${4} }
Anyway, thanks for listening and all the best,
Alec
The text was updated successfully, but these errors were encountered: