Comments (12)
It may be not absolutely matched with Avoid Mental Mapping (and Don't over-optimize). Maybe something like datasetPart
and chunkElement
?
And I don't know if this is in the book (I have not read it, unfortunately). Do the repository creators accept tips not connected with the book directly?
from clean-code-javascript.
It's about iterator and length variable naming, not the chunk or the element itself, so mental mapping does not apply (except if you want to name it dataset_iterator
and dataset_length
which would be a bit stupid to type often?
from clean-code-javascript.
Ah, sorry, I've misread the second cycle part.
from clean-code-javascript.
No worries :)
from clean-code-javascript.
Interesting, can you open a PR for that @cookiengineer? Thanks!
from clean-code-javascript.
Yep, will do one when I have enough time. Probably tomorrow.
from clean-code-javascript.
@ryanmcdermott Added a pull request :)
from clean-code-javascript.
I think this is relevant to mindmapping. Is there a significant reason for not opting for forEach()
to help reduce mindmapping (aside from some performance)?
You could use terms like group
and property
when using for-in
to help avoid mindmapping:
const dataset = [{ foo: [1,2,3,4], bar: [1,2,3,4] }];
for (let group in dataset) {
dataset[group].forEach( item => console.log( item ) );
}
Which can again be cleaned up (if we're flexible) to:
const dataset = [{ foo: [1,2,3,4], bar: [1,2,3,4] }];
for (let group in dataset) {
dataset[group].forEach( console.log.bind(console) );
}
from clean-code-javascript.
When using splice()
there's no way to get around a classic loop. forEach will continue and skip the next entry right after the deleted one. Only solution would be to use array[i] = null
, which will cause unboxing, boxing and an unnecessary GC run that could be saved.
While I agree and also prefer forEach for the sake of readability, I have to also say that forEach should not be used in a game engine's update loop that runs with 60 FPS+.
In my pull request ( #127 ) I kind of infringed the avoid over-optimization part... so I guess the forEach solution should be the one in the README though I still won't agree from the performance side of things.
The troubles newcomers will have when using functional ideas (filter/forEach/map/etc.) in update loops of their programs will get big once they have an interval. And I'm not talking about ms optimizations here, I'm talking about garbage beyond 10MB / min here that can be easily reached and will lead to program (or server) crashes. The "thinking in garbage" idea isn't contained in this guide and I think it's still important to know to write good ES code.
However, before I fix my pull request I'd like to have a vote on how people see this topic and what they prefer or to suggest to it. As stated, I'm always using lazy caching for projecting data structures and performant update loops. And I think that should be embraced.
from clean-code-javascript.
What's "lazy caching"?
Hmm... I like the don't over-optimize but yes it's understandable that you need optimization in game engines. Perhaps that could be a note or addendum? Although from my perspective, for the sake of speed, don't over-optimize on your first pass of development (even in a game) and then come back and make another optimization pass on your code. Not that I've ever developed a game before...
I feel like code is always going to need optimization, and you just don't want to get bogged down in it early on (especially at the detriment of your code's readability or refactorability which are crucial to long-term lifespan of code).
Overall, I see no problems with your example of using relevant letters, but I don't really like the use of 1-letter variables altogether. And I try to avoid nesting loops deeply enough that you need more than i, j, and k
.
I think personally it's not important to make sure your 1-letter variable is a relevant letter (since you're already using a much-harder-to-grok/scan variable name) and instead if you use something like a 1-letter variable, try to immediately swap over to a full-identifier object/variable so that it's use is extremely short. If you DO need to use the index throughout, then just call it index
or chunkIndex
? I use index
all the time as an argument for forEach()
or related functions.
from clean-code-javascript.
What's "lazy caching"?
Lazy caching is the idea to offload hard computation (map/reduce) off the computation loop and into the parts of the code where it changes.
let main = {}:
main.update = () => {
for (let d = 0, dl = this.dataset.length; d < dl; d++) {
this.dataset[d].update();
}
};
main.setDataset = (dataset) => {
this.dataset = dataset.filter(val => val.enabled === true);
};
If you DO need to use the index throughout, then just call it index or chunkIndex
My suggestion was primarily not about naming it index, but as index1, index2, index3, chunkIndex, dataSetWithMuchCamelIndex are shitty to read to suggest an alternative with the leading letters of the array it is related to - to reduce mind mapping overhead.
from clean-code-javascript.
What about dataItem
instead of d
? I'm still not sure what part of your example is the lazy caching.
I do agree about too many variables with bad names, but I feel like that's a symptom of overall a bigger problem with your code organization and changing from i
to d
isn't really going to be where the real impact could be had.
from clean-code-javascript.
Related Issues (20)
- Bonne pratique JS HOT 1
- J HOT 1
- Farsi translation
- The code example of <Don't ignore rejected promises> may be wrong.
- Nice HOT 4
- Contradict HOT 1
- De code HOT 5
- Js two HOT 1
- eslint plugin
- Add OSSF Scorecard security workflow
- Clean code HOT 1
- Close Issues with no description/details attached. HOT 1
- J HOT 1
- J
- I
- Clean HOT 2
- Js HOT 1
- Clean HOT 1
- Adding translations HOT 3
- CleanCode HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from clean-code-javascript.