Hacker News Reader

Comment by devjab | Hacker News Reader

Maybe I'm doing things wrong, but I assume this tool is meant to focus on cognetive complexity and not things like code quality, transpiling or performance, but if that's true then why does this:

(score is 7) function get_first_user(data) { first_user = data[0]; return first_user; }

Score better than this:

(score is 8) function get_first_user(data: User[]): Result<User> { first_user = data[0]; return first_user; }

I mean, I know that the type annotations is what gives the lower score, but I would argue that the latter has the lower cognetive complexity.

View on HN

I get the same overall FTA score of 7 for both of your examples. When omitting the return type (which can be inferred), you get the exact same scores. Not just the same FTA score. Also note that `Return<User>` should be just `User` if you prefer to specify the return type explicitly. That change will improve several of the scores as well.

> Also note that `Return<User>` should be just `User` if you prefer to specify the return type explicitly.

No? first_user = data[0] assigns User | undefined to first_user, since the list isn't guaranteed to be non-empty. I expect Return to be implemented as type Return<T> = T | undefined, so Return<User> makes sense.

You are correct if `noUncheckedIndexedAccess` is enabled. It is off by default (which is a pity, really).

I assumed `Return<User>` was a mistake, not a custom type as you suggest. But your interpretation seems more likely anyway.

Both score 7 now though.

This scores 6: function a(b) { return b[0]; }

This scores 3: const a = (a) => a;

Maybe because the type can be inferred and it potentially adds effort for changes in the future.

I'm not sure how you can infer types on this. Even if you input an array of users from a different function. How would we know that data[0] is a User and not undefined?

Then why use TypeScript at all? Just write js and put a TS definition on top. TS is a linter anyway. Now that will make the code easier to read, and in the end it is the code that will be interpreated by the browser or whatever JS runtimes.

> TS is a linter anyway.

Not really. TypeScript introduces optional static type analysis, but how you configure TypeScript also has an impact on how your codebase is transpiled to JavaScript.

Nowadays there is absolutely no excuse to opt for JavaScript instead of TypeScript.

What about debugging. Or with proper sitemap the code on the client-side can be debugged with the right map to the TS code? Just feels like an extra layer of complexity in the deployment process and debugging.

> What about debugging.

With source maps configured, debugging tends to work out of the box.

The only place where I personally saw this becoming an issue was with a non-nodejs project that used an obscure barreler, and it only posed a problem when debugging unit tests.

> Just feels like an extra layer of complexity in the deployment process and debugging.

Your concern is focused on hypothetical tooling issues. Nowadays I think the practical pros greatly outnumber the hypothetical cons, to the point you need to bend yourself out of shape to even argue against adopting TypeScript.

> (...) I assume this tool is meant to focus on cognetive complexity and not things like code quality, transpiling or performance (...)

I don't know about transpiling or performance, but cyclomatic complexity is associated with both cognitive complexity and code quality.

I mean, why would code quality not reflect cognitive load? What would be the point, then?

Reply on news.ycombinator.com