4 ms·
Eh. I think it's pretty silly. It basically boils down to "If you write terrible Coffeescript, it's hard to read". Duh? Any time you are writing code that is a
by cheald 14y ago
Eh. I think it's pretty silly. It basically boils down to "If you write terrible Coffeescript, it's hard to read". Duh?
Any time you are writing code that is ambiguous, use what you need to in order to clarify it. Don't omit punctuation just because you can if it makes the code less readable.
action(true,
option1: 1
option2: 2
)
Using empty parameters in a function declaration is even funnier; you're adding punctuation that makes the code more vague. Just omit it!
doSomething -> 'hello'
doSomething(-> 'hello')
The third example is totally valid, and one I completely agree with - omitting parentheses on inner nested function calls makes for unreadable code. Don't do it.
The fourth example - complaining that inconsistent indentation produces inconsistent results - is just incomprehensible to me. When you're using a whitespace-delimited language, you'd best pay attention to your whitespace.
Ambiguities with optional curly braces are certainly nothing new to Ruby developers. Convention is that only the last hash in an argument list may have its braces omitted (or more stringently, a hash may only have its braces omitted if it is the last parameter in the list). Makes for finely readable code. Don't write unreadable code.
One of the fundamental rules you should follow when working in any language is "don't be clever". Optional parentheses can make for very clean code, but if you try to get "clever" with them, you end up with ambiguous code. List comprehensions are awesome but if you use them when there's a simpler construct you can use, you're doing it wrong.
You can write bad, unreadable code in any language. Part of maturation as a developer is learning to write readable code, not just working code. A bad workman blames his tools.
- debacle 14y agoPeople make the same arguments about Perl, but CoffeeScript doesn't have CPAN. > Optional parentheses can make for very clean code, but if you try to get "clever" with them, you end up with ambiguous code. Seriously? Using extra parenthesis to add clarity is being clever? I always thought it was being safe.
- cheald 14y agoNo, sorry, omitting parentheses (because they're optional) can be "too clever". I love optional parentheses, but I feel like a lot of people omit them because they feel that they're supposed to, at the cost of code clarity. I'm arguing that you should omit them when doing so doesn't make the code ambiguous, but if you ever need them to improve code clarity, that you should use them. The OP had a fine example of "doing it wrong", with the nested inner function call without parentheses. While technically valid, it's bad code because it's difficult to read, even for someone accustomed to optional parentheses. Such a construct is "clever" when it shouldn't be.
- bjourne 14y agoBut then you have to think everytime whether you should put parantheses there or not. Is the code readable without parantheses? Should I put them there in case someone reads the code in a year and doesn't know about the problem domain ... ? It is not much, but it is extra cognitive load that is wasted. It's akin to programming C and everytime you write a function, if statement or for loop you have to ponder whether it looks best to put the opening brace below the line or at the end of it. I hate reading code with an inconsistent brace placement style like that.
- fatbird 14y agoIf writing good, maintainable code requires knowing/using a large number of rules and best practices that aren't part of the language (and whose absence are actually considered to be a virtue of the language), that seems like a flaw in the language itself. Yes, you can write bad code in any language. That doesn't mean that languages don't have an impact on the ease of writing good and correct code.
- cheald 14y agoIf you think that the existence of style guides are a flaw in their respective languages, then I'm going to (as non-condescendingly as I can via text) suggest that you may not be a very mature developer yet. Style guides and best practices exist for every commonly used language, and not because of flaws in the languages themselves, but because unless there is literally only one way to do things, a dozen developers will come up with a dozen ways of solving a problem.
- fatbird 14y ago"as non-condescendingly as I can via text" Yeah, that didn't work out so well. There's a difference between style guides offering a well-lit path to follow, and a language having a large number of possible expressions that are off limits in practice because they lead to bad code. The former marks out a path, the latter indicates a minefield. When the language's design actually facilitates the creation of bad code, not just by offering the possibility of dangerously ambiguous expressions, but by touting that possibility as a plus, that's a flaw. Maybe accepting that flaw is worth it because the expressiveness of the language makes it a net plus; doesn't mean it's not a weakness or flaw or a point to be cautious about.
- cheald 14y agoI do apologize - I didn't mean to be perjorative. I meant to communicate that I've heard the sentiment ("why does it let me shoot myself in the foot? It shouldn't let me do that!") espoused by many, many new developers, and it's an attitude that I've seen many people grow out of. Coffeescript is a very flexible language. Its flexibility lets you do bad things with it, but the flipside of that attribute is that you can do very good things with it. I don't think that it's either "a path or a minefield"; I think those are two sides of the same coin. Optional parentheses and whitespace delimiting can reduce visual clutter, but if you abuse them and reduce it too far, you increase cognitive load on the person that has to read and maintain the code. The more stringent the language, the less guidance you need in the form of style guides and community standards, but that's simply because the language itself imposes those standards on you as a byproduct of disallowing flexibility. It's absolutely something to be cautious about, but it doesn't make the language inherently flawed.
- city41 14y agoI agree with you in theory, but in practice when working on large teams, languages as flexible as CoffeeScript do become a problem. That's a major reason languages like Java and even C# are so inflexible. For my personal projects or small teams I'd have no reservations using CoffeeScript if it felt like the best fit. For large teams, I'd reconsider.
- njharman 14y ago> "If you write terrible Coffeescript, it's hard to read" No, it's "If a language that provides for many ways to write terrible code (incl many ways to write the same code), people will write hard to read code." For example if parens are required, it is impossible to "get clever" with not using them. > A bad workman blames his tools Great workmen evaluate and avoid bad tools.
- masklinn 14y ago> No, it's "If a language that provides for many ways to write terrible code (incl many ways to write the same code), people will write hard to read code." A prime historical example being Perl. A second one being PHP.
- debacle 14y agoPerl is a great example because it is an amazing language with a horrible reputation that it mostly deserves.