SIMPLE appears to be leaning even more towards the functional programming side of things; I think we should probably just get it over with and accept that composition of functions operating on immutable data structures is just the right way to go.
Combine that with multi platform productivity. If you do want to get dorkier there are fully functional libraries.
Yeah. No. Maybe. The cost of immutability can be high. Immutability can be very elegant when it's right, but mutability can be clearer other times. As another respondent said, there's no silver bullet. There's no 'right way to go'; as ever it depends.
If you analyze expenses for software projects of 1960-80ies and compare them with recent years, you probably see that the most expensive item now is at the bottom. The most costly thing used to be hardware. The not so expensive - developer's time. Now it's the opposite - the equipment is cheap, and the software developer's salary is the most expensive thing. Of course, that does not apply to every single case, but for the majority of projects, that is true.
Immutability by default (baked into the language), offers enormous benefits, and increases programmer's productivity, it simplifies many things, especially concurrency and parallelism. Languages like Erlang and Clojure are good examples. The price you are talking about does matter. But very often, the benefits outweigh the small cost.
Functional programming as it exists today takes these ideas to a somewhat extreme form. That has its place and value, but as experience in the real world shows, as long as it feels so mathematical, it isn't everybody's cup of tea. Hopefully, over time we find more intuitively accessible abstractions for the really useful principles that functional programming is based on.
Languages like Elm, Elixir and Clojure don't feel "so mathematical".
It can provide an incremental improvement but it is https://en.wikipedia.org/wiki/No_Silver_Bullet
I can’t count how many times I’ve seen error messages that look like this, often with no context at all, in JavaScript apps, even widely used ones like npm and webpack. Proper error handling is never easy, but the JS community seems particularly given to avoiding it.
If everything at the bottom is straightforward, then people will spot more overarching concerns, instead of bogging down in minor details.
I’d really love to see some cognitive science applied directly to UX and code quality concepts. Surely some of the things we espouse but don’t enforce are spot on, and others are cargo culting. Refining that list might make it harder to ignore.
it would be also very educational to see decision and design process of an app build with those rules.
Also; keep it clean. Don’t over-comment, but comment.
Moreover, when a lot of people are asked to comment they write stuff like "this function does x to y" when the function is named "x_to_y". No shit sherlock comments I call them.
I'd always prefer to have good comments, but I've worked on a lot of code bases where no comments wouldn't really have been any worse.
Writing good readable code is hard, and you don't get it just by banning comments.
Much like how you don't lose weight by buying smaller sized clothes :)
If, in a brief sentence, written in plain English (or any other language of your choice), you can't explain the idea, you need to "go back to the drawing board." Resist the urge writing it in a programming language before you can explain it in English.
When you're done writing the function, go back to the docstring, revise it; in some cases, you can even remove it.
The purpose of a docstring is to help humans to quickly scan the code and discern the meaning, the idea of the function without having to read its source. Like a trailer for a movie - it should give you the general idea, but not give away the implementation details.
Think about docstrings as "type annotations" for humans. We use types and type hints "to help the compiler understand our code better" because computers do not understand plain English, but very often, we have no empathy for fellow programmers.
There have been a number of cases where, for instance, I had to call a bizarrely named API and do something unexpected in order to get an unintuitive outcome and in that case a "what" comment isn't such a bad idea.
The beginnings of functions, for instance, are great places to comment, perhaps even including a definition of some of the subroutines within it.
In the case of an exceptionally large subroutine, commenting within the subroutine may be advantageous - but at that point you may consider another function to replace that larger chunk.
Variable names that are perhaps obscure and are not practical to rename for whatever reason can also use comments.
Class headers are of course also a great place to comment, to explain the purpose of the class.
Good comments can lead to better code. :)
I've seen it happen many times now. A nice, clean, easy-to-read code base turns into a forest of unreadable shit thanks to the introduction of parsed comment tags. Perl, Ruby, Python, JS. Doesn't matter what tool or language.
Please, people. I beg you. Stop putting this shit in code. Not everyone is using the same bloated IDE as you, nor do we care to maintain your silly block text and parameter text that is outdated the day you wrote it. If your function needs a block text to explain how to use it, you need to find a new job. I'm serious. You're not good at your job. If it's not self-evident what the file you're looking at does and the function within the file does, then refactor it. Cut it down. Make it make sense.
Nothing wrong with that!
//increment i in for loop
For (i=0;i++....
Var x; //define variable x
X=4; //give value of 4 to x
Sorry, can't read behind paywall.