Hacker News new | ask | show | jobs
by Pyxl101 4029 days ago
Why is it crazy? I've wanted this feature recently in other languages. Just because someone else wrote FunctionName doesn't mean that I want to write it that way.

Case insenstive search solves the matching problem adequately. You could also do underscore-insensitive searching.

Why is it a problem, or crazy? It's a natural extension of being insensitive to whitespace and formatting. If you like your code to look_like_this, fine. Someone else PrefersThis. It can all interoperate. I think that's great. Leave style to each person's preference.

2 comments

>Just because someone else wrote FunctionName doesn't mean that I want to write it that way.

If it's different codebases, you can do that in almost any language. Have some comebases write fooBar and others write foo_bar or whatever, whatever each one prefers. It's not very good even in that case, because you'll often have to read somebody else's codebase (which is why people praise go fmt and organizations have coding guidelines), but at least there it's OK.

But if you're talking about FunctionName and functionName and function_name in the SAME codebase (and obviously you do, since for the previous case you don't need Nim at all as I said) then that's were madness lies -- willingly impairing yourself to identify optically a symbol to be the same as another or not, because it can have 20 variations...

I've never found this "flexibility" and bike-shedding that ensues useful in any language. I'd even prefer a fixed brace style, even it's not the one "I like". It takes a few weeks of familiarity to learn to perfectly see a different formatting style and even "like it".

If we were following this idea, then I think source would be displayed according to your preference whenever you looked at it. You'd never need to deal with multiple symbol variations. The goal would not be to use multiple styles in on code add so much as make style entirely personal.
> Leave style to each person's preference.

That's fine for hobby projects. That's pretty much the last thing you want for a codebase of a significant size. I don't like C#'s style conventions, for instance, but I'd rather work with a language that has uniform style conventions I dislike than in the free-for-all you get with Nim.

Python's "There should be one-- and preferably only one --obvious way to do it." applies to style as well.