brian

joined 2 years ago
[–] brian 1 points 2 months ago

this, evil is the real 4th generation vi

[–] brian 1 points 2 months ago

this is neat but also is a closed source extension. I use https://github.com/Wilfred/difftastic which doesn't do quite as much and doesn't integrate outside of git's diff, but is still significantly better than nothing

[–] brian 2 points 2 months ago

that's not a one letter template literal, that's built in python syntax. it only has combinations of u r and f and no user defined option. f makes it templated

[–] brian 2 points 2 months ago (1 children)

just stick a verification task in ci. if I have to check if the format matches the standard in a code review instead of reviewing meaningful things my time is being wasted

[–] brian 3 points 2 months ago

the codebase readability certainly suffers, and this isn't the only case of shenanigans like this

[–] brian 8 points 2 months ago (2 children)

found the following in our codebase the other day.

while(booleanFlag)
    return;

thhere wasn't more in the loop body, that was it. the loop conditional does exist and it can hurt you.

[–] brian 1 points 2 months ago

if you're copypasting you're not using the code reuse tools of your component library. the nesting in normal css is component nesting with tailwind. and if you're copypasting things that aren't just the same component styles but something else shared, it's just a string you can stick it in a variable.

[–] brian 3 points 2 months ago (2 children)

idk if nesting is the reason people used tailwind. imo it's more that css itself is a lot of complexity and overhead to write if you already have nesting and reuse in whatever you're using to produce html, ex react. I'd rather not have to maintain a css tree and a component tree when it can all be colocated.

writing raw html? yeah tw doesn't make any sense

[–] brian 9 points 2 months ago

or if you really wanted qt, using java qt bindings: https://github.com/OmixVisualization/qtjambi

[–] brian 4 points 2 months ago

linting config itself wouldn't be defined there, and it would be verified in ci and such, but a setting to tell vscode which linter and extension it should use to show warnings would be.

modern languages may have their own way for configuration but they don't have a way to bind it to the list of vscode tasks and define how to run a debugger, which is the part that gets stored.

it's easy to go overboard with extension suggestions, but I don't think adding an extension for linter used, extension for formatter used, and any languages used if there's a definitive extension.

My team is split between visual studio, vscode, and I use emacs. we have config for both vs and vscode in our repos since it makes working on a new project so much nicer and means we aren't just sharing editor configs through side channels instead. it doesn't do anything to me if I have editor config for an IDE I don't use in the repo, but it makes it easier for someone new to jump in with a sort of same environment immediately

[–] brian 15 points 2 months ago

but if there's a bug I'll know exactly which line to look at

[–] brian 8 points 2 months ago (2 children)

that doesn't sound right, it's so much smaller if it's just one line

view more: ‹ prev next ›