Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm a javascript developer for a year now but I lack some architectural/engineering background as I was lazy in college.
In the beginning I was writing small scripts with relatively small and simple objects.
As my projects are getting bigger, I tend to use bigger and more complex objects which reflect 4-5 basic data structures which I use in various parts of my application.
I'm looking for the best way to document/keep track of the structure of these objects because when I make a new module that will use one the them, I have to make use they will respect their structure and interface so the previous/next modules using them won't break.
What I was doing until now was to document an object like this:
/** description of the object/data structure
var myObject = {
property1: "", //explain here what is this property and what type it is (number,string etc)
property2:blabla,
etc...
}
*/
This ended up to huge parts of comments which are ugly in the code and distructing too.
Could you suggest some ways of either visualize my objects/data structures or document them so I can fast recall how they should look like?
There are several tools for that out there, but here's a few:
njsdoc - "NJSDoc is a Documentation tool for JavaScript that
works by executing code."
JSDuck
jsdoc
YUIDoc
Natural Docs
DocumentJS
I think you might be interested in the information provided here:
http://javarevisited.blogspot.gr/2011/08/code-comments-java-best-practices.html
It's about java but they can also be applied in Javascript (some of them)
Summarizing the key points:
Focus on readability of code
Don't write what code is doing
Always write why you are writing this piece of code
Always try to finish your comment in as few words as possible
Always put comment while commiting code in source control repository
Give your code to fellow developer to understand
Regarding your code, I have to say that from personal experience I find that writing comments on the previous line rather than next to the code, is more clear and easy to read.
E.g.
var myObject = {
//explain here what is this property and what type it is (number,string etc)
property1: "",
property2:blabla,
etc...
}
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am building a three.js library and found placing comments and nesting content below the comment in {} made it easy to navigate lots of code. I was wondering if there are other better ways to do this.
Why I would like to do this
the main reason: I can quickly collapse code based on the comments I see above the block scopes. Thereby making it easy to focus on the code I want to change.
I'd only use this in the class initialisation, or very complex methods. Or rather, any areas where there is significant code use with applicable labels for those areas.
I would never scope a section without an appropriate comment accompanying it.
This helps me scale these different sections, especially if they are not something that would scale into a new class or object within reason
Im aware a common problem with code bases is they can be extremely overwhelming, especially when learning them. I think this way of organising code could help make it more approachable and less overwhelming to look at
I would love if there was a feature in IDE's to do something like this
Example of its use:
Collapsed:
Un-collapsed:
Collapsed:
Un-collapsed
I also see this as a compliment to refactoring, whether it's abstracting into functions or more classes. This seems to be agile and deals with uncertainty in the code base especially if you need to neatly layer problems solutions into themselves in ways that would not qualify a new class, or new method.
I would say it's better to break down into separate functions. Adding unnecessary blocks could have surprising consequences for future maintainers. Many editors support using a special syntax within comments to aid code folding and navigation without altering the syntax tree.
[Edit]
Whilst I am really an Emacs-only guy (TM), the docs (https://code.visualstudio.com/docs/editor/codebasics) for Vscode suggest something along the lines of
//#region
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I’ve been working with JavaScript for around 4 years. In all the applications I’ve worked on, I’ve never once seen someone use a linked list. Why is that? Data structures are so prominently featured in most learn-to-program courses. Yet I almost never see them used in the real world.
This may not be the perfect explanation of this but I think will give you a fair idea about it.
The scenarios which will make sense to use Linked list on JavaScript
are very rare. You have been working on JavaScript for 4 years when
did you feel a need to use linked lists and not JavaScript Array
The main purpose of using linked list is performance improvements,
when there a is a huge collection of records and frequent changes to
them linked lists help in optimizing that. But that case may not be
true for most of the JavaScript applications. Arrays are pretty much
bale to do that for JavaScript.
Most of the frameworks rely on array's be it React, Vue etc.
In case of linked list methods like unshift, etc. are much faster.
while methods on Arrays, such as push, run considerably faster than
Linked Lists.
The use of linked list is justified when you need to make a lot of
modifications to a huge list — especially when adding or removing
items somewhere other than the end of the list and such cases are rare in
JavaScript/front end.
Last but not the least JavaScript has great support for Arrays but
you will have to code your own implementation or use some library
that provides linked lists implementation.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm rewriting a JavaScript library that I wrote some time ago.
Its purpose is to display an array of objects as a table, that can be sorted, filtered and edited without server communication.
The current solution "pollutes" the objects with additional attributes, that are needed to steer the display.
The original object may look like this
{"name":"...","lastname":"...","age":27}
And then it has additional attributes like this
{"name":"...","lastname":"...","age":27,"TTMDecode":true,"TTMChildren":[]}
An alternative Solution may be to only wrap the original object and then work with these wrappers.
{"decode":true,"children":[],"data":{"name":"...","lastname":"...","age":27}}
I'm not sure which solution is preferable.
With the second solution it's easier to return the original object to the server, in the case it was changed, but it doubles the amount of objects for the JavaScript engine.
The solution is able to work with over 20.000 objects and it's fast in current browsers.
But will 40.000 Objects be a problem?
I hope I explained my worries good enough.
Regards
First, about your architecture problem: why not make a parent object with the two properties display and data ? You should not limit your architecture because of performance worries, if it has effect, you will notice it when measuring the performance.
var obj = {
display: {
// display data
},
data: {
// personal data
}
);
Which implicitly answers the question about the object count, this normally does not matter (if the objects themselves are not huge, it won't affect your performance)
What you need is a design pattern. You happen to already be using one.
First, you should not pollute a model with things needed just for the view. This is not the same as saying you can't have convenience methods or computed properties on the model. A red flag indicating you are doing it wrong is if something specific to your view layer, like DOM, is on the model. I don't know what TTMDecode is in your example...
Second, you are already using design patterns. You are using composition to decorate your model objects.
See this for a description of the Decorator Pattern,
and this for a description of Composition.
I think you are doing fine.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
This might seem like an odd question, but I find that javascript is either easy or hard, depending on how you've coded the HTML. Is there a book or website that goes into detail about successful patterns and guidelines for coding HTML, so that it's very workable with jQuery, css and complex ajax applications? Like solid rules to live by.
Again, seems like a weird question maybe, but I don't know a better way to ask it. I just find myself always having to change the markup as new things come up - like switching between a hidden input element to a data attribute... or putting more ids or taking away ids - and I guess I arrive at the right way to do it, but I'm curious if someone has bothered to analyze this and came up with some great guidelines, standards and patterns so that the resultant HTML is right the first time.
Thanks
The first thing if you want to code some clean HTML that will be easy to work with is to make sure that your code is valid against an official DTD, HTML4 (here) or XHTML (here).
Then use id and class in a proper way (id only for unique section and class for repeatable ones) and name them correctly according to the context so they are easily reachable.
From my experience, I would actually suggest that, when it comes to large projects and professional JavaScript coding, the goal actually becomes to decouple the JavaScript code from whatever HTML it lives in.
As mentioned already, as long as you are using well formed HTML (DTD compliant), a library like jQuery shouldn't have any trouble operating on it. However, as best practice, I would recommend striving to isolate and encapsulate dependencies, whether they be because of HTML structure or just other chunks of JavaScript code.
the best way is to develop the html and javascript together. That way you can adjust the document structure to whatever you need.
This article seems to answer my question:
http://www.viget.com/inspire/extending-paul-irishs-comprehensive-dom-ready-execution/
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have a JS script (widget) which is added to other websites. Technically its similar to Google analytics. My question is: what are your advices for ensuring robustness, keeping the code from interfering with other code on the site, avoiding errors for users etc. In general, what should I know to write a professional grade widget.
Notes:
I can't use any JS library such as jquery etc..
I am a big fan of Peter Michaux's guide on how he writes javascript widgets
Also useful are Christian Heilmann's script configuration and the module pattern
Those are generic javascript articles and aren't specific to a single library
Other useful tricks are things like wrapping your code in an anonymous function to stop it interfering with other global libraries.
(function() {
//Your code goes in here
})();
Regarding errors and best practice, John Resig has an interesting article on javascript strict that isn't in yet, but does have some handy information on the sort of things you should be avoiding.
If you're still coming to terms with scoping within your objects, then you might find this article on private and public variables useful as well a a bit more technical definition by Douglas Crockford
Finally, remember to run your completed code through a code quality tool