>
> Refactoring these to fit any cyclomatic limit also makes code worse and
> not worth it. But increasing global limit because of these exceptional
> cases doesn't makes any sense - instead, just add pragma to such func:
> func validateSomething() { // nolint:gocyclo
I feel the same as you in these cases you mentioned. The solution you
proposed made me think that if we could have a pragma like the one you
described, but for specific branches/path, that could be helpful. Example:
if { // gocyclo:skip
Having that, the linter wouldn't need to have a logic to decide whether it
should compute a specific branch or not. Would be up to the developer to
decide, easy to be configured, and not obscure in any way.
On Friday, April 13, 2018 at 5:15:09 PM UTC-3, Alex Efros wrote:
>
> Hi!
>
> On Fri, Apr 13, 2018 at 12:41:35PM -0700, Lee Painton wrote:
> > The only situation in which this limit has seemed unreasonable is when a
> > large number of independent cases followed a selection function (a large
> > case statement), which was allowed.
>
> Another situation is function which does validation of complex data
> received from outside - like checking flags in main() or http.Request in
> http handler func or similar RPC handler func.
>
> Refactoring these to fit any cyclomatic limit also makes code worse and
> not worth it. But increasing global limit because of these exceptional
> cases doesn't makes any sense - instead, just add pragma to such func:
> func validateSomething() { // nolint:gocyclo
>
> Just try to avoid mixing such a validation logic with another logic in
> same function.
>
> --
> WBR, Alex.
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
