3 ms·

If you already have a linter, I suggest going a step further and automating the JIRA issue creation when a TODO without an associated issue is found. Nothing b

by mhitza 5y ago

If you already have a linter, I suggest going a step further and automating the JIRA issue creation when a TODO without an associated issue is found. Nothing breaks flow quickly than getting stopped by a linter, when an autofixer could be used behind the scenes without ping ponging the developer with linting errors.

capableweb 5y ago
> If you already have a linter, I suggest going a step further and automating the JIRA issue creation when a TODO without an associated issue is found. That's a huge jump in complexity and possibly introducing security issues. Not only does the CI now need to lint your code, it also has to have credentials to your planning tool, and logic for creating issues there when specific things end up in the code. All because a developer couldn't be bothered to add a ticket in the planning tool? > Nothing breaks flow quickly than getting stopped by a linter, when an autofixer could be used behind the scenes without ping ponging the developer with linting errors. Linting errors should show up right before commits, and (by default) prevent developers from committing if the code doesn't work (by the standards of linting, checks and tests). This is no different from static type checking then. If you're waiting for CI runs to see what's wrong with your code, then your feedback cycle is already too slow.
- mhitza 5y ago
  > That's a huge jump in complexity and possibly introducing security issues Possibly, I have been blessed in not having to directly deal with Jira's complexity in years. On the other hand if it has support for no read, post only ticket type permission for API tokens I see no issue. > Linting errors should show up right before commits That's an opinion I do not share. Don't waste my time with linters that can autofix things for you. A linter is different than a type checker. Sure some type checkers are implemented as linters, but a bunch of linters are style preference enforcers. In short my opinion is: if your linter has a fix option, drop that in your PR CI and have it autocommit.
cdcarter 5y ago
Oh no! A TODO is almost never written with the level of detail I'd want in a JIRA ticket. I think usually, if I'm leaving a few TODOs in a checkin, it's to highlight several locations where a single change needs to be made. Automatically creating new tickets for each call site sounds like hell.

by mhitza 5y ago

capableweb 5y ago

> If you already have a linter, I suggest going a step further and automating the JIRA issue creation when a TODO without an associated issue is found. That's a huge jump in complexity and possibly introducing security issues. Not only does the CI now need to lint your code, it also has to have credentials to your planning tool, and logic for creating issues there when specific things end up in the code. All because a developer couldn't be bothered to add a ticket in the planning tool? > Nothing breaks flow quickly than getting stopped by a linter, when an autofixer could be used behind the scenes without ping ponging the developer with linting errors. Linting errors should show up right before commits, and (by default) prevent developers from committing if the code doesn't work (by the standards of linting, checks and tests). This is no different from static type checking then. If you're waiting for CI runs to see what's wrong with your code, then your feedback cycle is already too slow.

mhitza 5y ago
> That's a huge jump in complexity and possibly introducing security issues Possibly, I have been blessed in not having to directly deal with Jira's complexity in years. On the other hand if it has support for no read, post only ticket type permission for API tokens I see no issue. > Linting errors should show up right before commits That's an opinion I do not share. Don't waste my time with linters that can autofix things for you. A linter is different than a type checker. Sure some type checkers are implemented as linters, but a bunch of linters are style preference enforcers. In short my opinion is: if your linter has a fix option, drop that in your PR CI and have it autocommit.

cdcarter 5y ago

Oh no! A TODO is almost never written with the level of detail I'd want in a JIRA ticket. I think usually, if I'm leaving a few TODOs in a checkin, it's to highlight several locations where a single change needs to be made. Automatically creating new tickets for each call site sounds like hell.