Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
When it comes to naming elements, should I use 'class' names for CSS & 'id' names for JS?
Is there a different rule of thumb? Should I just use one name?
Any insights/suggestions would be welcome.
It's a little more complicated than simply going with class and/or id for your naming conventions.
In fact, JavaScript and CSS should be handled in very different ways as far as naming and identifying elements. I'd recommend checking out this guide on beginning CSS or if you want to challenge yourself and build styles that are really versatile and reusable, check out this article on semantic class names or Meduim's CSS is Actually Pretty F***n good by #fat (one of the guys who made the bootstrap lib)
Note that these are opinions and you have a lot of freedom with CSS, it's about being creative, but also making something that if you died someone else could understand and leverage your code.
JavaScript is something that can more easily turn into a mess if you don't follow some good practices, I'd check out some of the links at the bottom of this post, but the important thing is that you are consistent, verbose, and use comments and tests. In regards to naming HTML elements for manipulating them, if you are sure that you will only have one element per page that you want to perform certain actions with (for example a username field on a login form) than an Id is acceptable and makes sense, so long as the naming is consistent (for example: don't call your username field on a login form id="name" as that could be misconstrued, instead call it id="username" or id="login-username") making a name clear doesn't waste a significant enough amount of memory and network bandwidth to replace all the headaches a future developer could have trying to figure out what is going on with the id's and classes.
When it makes sense to use a class for identifying a collection of elements in your page via javascript - make a point to use a classname specifically for your javascript - perhaps prefix it with js-<classname> or make it a stateful name such as is-selected so that you 1) know when looking at it that it might be something that could be useful to manipulate in javascript code, and 2) so that it doesn't get confused or convoluted with your styles in your CSS.
In short your goal should be to have consistency and clarity in your naming - sometimes it might mean an id(when you only want there to be one of something on a page) and other times it might be a class(when there may or may not be many of them on a page) - just be thoughtful of whether it would make sense to someone looking at it for the first time.
link dump:
opinion 1 on js variable naming
opinion 2
opinion 3
note there are tons of opinions out there - again its more important to be consistent rather than whatever people say is the best practice for the year (but you will find that people tend to follow some naming basics such as all caps for constants and camelCase for javascript variables, etc.) - read up, pick what you like and go with it.
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 6 years ago.
Improve this question
I've been reading the google naming convention https://google.github.io/styleguide/htmlcssguide.xml
I've gotten the most down. However I still feel itchy when it comes to certain naming of things which include two or more words. A prime example is the following; sign in.
JavaScript:
var signIn; // this feels natural
CSS:
.sign-in-container { ... } // for me this feels unnatural
.signin-container { ... } // feels more natural for some reason
.signIn-container { ... } // goes against css naming
It's unnatrual because most of my css classes a hyphen seperates heierchary or function.
I was reading about the actual word sign in and it says signin can be mistaken for signing in some cases.
Is it worth putting a hypen between sign and in. I'm most likely overthinking this, but as a programmer, sometimes small things really get to me.
Would this effect SEO for example? Is there any reason at all to prefer or not prefer putting a hyphen between them?
Best go with what is recommended in the language you are writing in. In JavaScript you should stick to camelCase, however this is rarely used in CSS. Besides, this way one can't make use of the |= attribute selector.
That leaves us the last problem: should one use a dash in order to improve meaning of a variable, or should one avoid it in order to be consistent with similar variables?
.cart-container {} // prefix `cart` specializes the container class
.blog-container {} // just like `blog`
.sign-in-container {} // however, this one isn't consistent this way
I prefer avoiding it, but it might be a personal preference.
I'm most likely overthinking this, but as a programmer, sometimes
small things really get to me.
That's a common mistake programmers make I guess. The key is to fence of this in order to improve your productivity!
Although I highly discourage over thinking this, like you said. There are a couple of ways solving this problem:
Choose a different name
Like .login-container, which basically means the same.
Create a more generic selector
Like .main-container, .content-container or maybe even .responsive-container if it needs to be responsive.
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 8 years ago.
Improve this question
I use JSDoc to document all the JS I write, but I am curious about how people document their less. I guess I could use JSDoc, but it doesn't seem right since less is not JS. I also want to avoid documenting my less with JSDoc if there is a standard way that might allow different IDEs to provide tooling support.
Does anyone know of a standard way of documenting less?
Documenting source code involves different issues, and may have different objectives, than documenting CSS, be it LESS or any other variant.
Source code involves classes and methods involving contracts, such as the types and meaning of parameters and return values. It also may have complex logic that requires explanation, or handle multiple conditions, or deal with various edge cases. It may be implementing an API which third parties will consume, which should have its own stand-along documentation that can be "read". Systems such as JSDoc are designed with all this in mind. People reading the code can easily understand the purpose and signature and logic of the various routines, and the comments can be processed into API documents.
In a similar vein, source code is typically organized logically into a hierarchy of modules and classes. When reading the documentation, it's common to want to jump from a description of a subclass to the description of its superclass, or up to the module level. Tools like JSDoc also make this easy, by spitting out sets of interlinked HTML pages, most often.
On the other hand, consider a library such as Underscore, to which only some parts of the above apply. There are no modules, or classes, or class hierarchies. Instead, it is a bag of tools. Therefore, there is really no need for a lot of JSDoc-like machinery. Instead, what I want to do is to be able to READ the code and easily see what's happening, or get a narrative about the functions provided, probably with some code examples. That's why they use Docco, as recommended by a commenter. It's perfect for that. And as the commenter also mentioned, it can be used with almost any programming language, including CSS.
Compared to "languages" like JavaScript, CSS is (typically) flatter, and does not have the notion of "contracts" of parameters and return values, nor complex computations, although in systems like LESS of course you have mix-ins and calculations. With CSS, you also have the situation that in many cases the effect of the CSS is something visual, like say a button colored a certain way with text of a certain size. We have two potential consumers of comments in CSS: the programmer who is actually looking at the CSS code, and the UI designer or implementor who wants to know what styles are defined and check how they work.
Personally, I would adopt two approaches here, mapped to the two types of consumers. In the CSS code itself, I'd simply comment narratively, describing the purpose and structure of the rule. Parallel to that, I'd build a separate "styleguide" site, which contains visual examples of all the styles. There have been various attempts to automate the creation of such styleguides, with varying degrees of success. I have not used them, so cannot say how useful they might be. Personally, I'd go with a hand-rolled style guide.
It's also worth pointing out that the only thing worse than no documentation is wrong documentation. Whatever documentation approach you take, you have to make sure it's really sustainable and maintainable. In that sense, simpler is better.
Finally, let me note that the need for extensive documentation is inversely proportional to how well designed a set of styles and classes is. There is not much point in papering over baroque designs with poorly factored classes, weird dependencies, and poor naming, with lots of documentation. Instead, you might want to focus on refactoring your CSS so it's at least a bit more self-documenting.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking for code must demonstrate a minimal understanding of the problem being solved. Include attempted solutions, why they didn't work, and the expected results. See also: Stack Overflow question checklist
Closed 9 years ago.
Improve this question
So, I have a website with a search bar.
I have only figured out how to get results when they match (at least in part using Like %searchterm%) and it works.
Obviously, this does not help me if the user misspells something.
We have discovered through HeatMapping that we are losing people on this.
How can I implement a "smarter" search feature?
Thanks,
Yoni
The "real" solution that you are looking for might be more complicated than you think. You could use simpler solution that will work fine like using the DIFFERENCE function.
I am trying to leave a comment, but not able to. So i have to leave it here, and it might not be the ideal answer Yoni is expecting. I can think of two ways of doing it.
use asp.net autocomplete function. It will query the db, and feed the user back with suggested search results dynamically when users are typing which will prevent users mistyping somehow. many search engines use it frequently like Google, Yahoo. In asp.net, its very easy to wire it up.
ASP.NET Auto Complete
This is how Auto complete looks like
add a class to re-process the search terms before querying the database, so you wont get 0 hit if users mis-spell or mis-type something. This is very broad, and it varies a lot depending on your business model concept.
Hope it helps. :)
This is quite a complex matter, impacting on both coding complexity and query performances.
Of course there may be a lot of approaches to achieve the results you ask for.
Personally, I would start by working with aliases: for each word that user may search for, I would create a set of aliases, that may be related to word semantic value or to mistyping of the word itself, eg:
Word: sheet
Aliases: paper, shet, shee ...
So, each single word must be indexed (and this could be a cumbersome aspect to deal with, depending on your contents), and for each woed there may be many aliases.
Then apply a sequential logic like the following:
1 - standard search, as the one you already did
-> if nothing matches
2 - alias search
-> if nothing matches
3 - start "playing" with wildcard characters (this could definitely kill your db however)
I understand this is a quite generic answer, but I don't think there may be an absolutely good approach - performance wise - to your question.
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
In a continuous integration, agile environment, if I make a change in class A (e.g. change attribute names) which I have created and have been working on, that affects class B, which "belongs" to someone else, who modifies class B whenever I want to check in my change? Me or the class' B owner?
I suppose is more agile if I modify it, so that I don't have to notify other people, but at the same time, people working on it are more aware of the impact of modifying it...
In an agile environment, class B (like all classes) belongs to the team. We call this Shared Code Ownership. You should check in working code; if that means you need to adjust class B to conform to the changes you make to class A - adjust! Better yet, pair.
"Individuals and interactions over process and tools." Communicate the change upfront with the other people impacted. Unless the code is trivial, you may not understand the full impact of the change. Even if you do, you owe it to your other teammates to keep them informed.
"Don't break the build." Checking code in that you know will break the build is not a good idea. Once you have communicated with the others that are impacted, work with them to get the code changes completed. Attempt to get the code changes checked in so at least the nightly build is not broken.
Just my opinion....
Bob
who modifies class B whenever I want to check in my change? Me or the class' B owner?
With no disrespect, I think your question is so basic that it clearly suggests that you do not have even basic understanding of what being Agile means. Well, maybe that's why you asked this question.
Here are my suggestions:
In this kind of situation you really should walk up to the other developer who might be impacted by your change and have a quick face to face conversation about this, this quick conversation may lead to you guys pair programming to make sure the build does not break, and no one gets affected.
Please read all the Agile Principles again, and write down what you understand from each one of it. Implement those principles in your day to day development life. This is the only way to become Agile. There is no certification or book to refer to, to make someone Agile magically. Being Agile has to be self realized, hence practice them daily till they become a habit.
So the "Information" is conveyed using the most effective method i.e. f2f conversation. The problem is solved on the basis of the collective responsibility principle, most ideal way to fix it is pair programming.
Reference:
Agile principle
"The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation."
Also a general Agile Guideline from the manifesto:
"Responding to change over following a plan"
Agile includes team code ownership, communication
As #Carl Manaster said, the code belongs to the team. And as #rcravens suggests, agile is about communication. Have a quick meeting with the author of B and let them know your proposed changed to be sure you understand your impact. If it's complex, pair with B's author on the change. When the change is complete, if you think it might affect other developers on the team, call a brief team meeting and let them know of the change.
By the way, how's your design?
Your question may aslo be revealing a design issue - A and B might be too tightly coupled. After your tests work and you've implemented the change, I suggest that you examine your code and see if something needs refactoring. (Remember, TDD is Red/Green/Refactor) In particular, if changing class A means you have to change class B, then you might not be following the Single Responsibility Principle (SRP) arm of SOLID practice.
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 5 years ago.
Improve this question
Scrum development is based on listing user stories and implementing them in during sprints. That approach - focusing on actual goals of the end product - definitely has its virtues, but what bugs me is that it doesn't advocate creating any generic/reusable code in the process, and actually I feel like it advocates hacking. For example, if an user story says
Must be able to plot x versus y, and fit a line there.
my first thought is that, "hey, I need to create a generic graphing framework so that I can handle similar cases more efficiently later on". But that's not the goal in the scrum sprint; the goal is simply what the user story says.
So it is more desirable (from Scrum viewpoint) to simply hack something together so that the user story gets implemented, instead of trying to understand the big picture and creating something more generic (which, of course, takes more time initially).
Is this unavoidable? Have I misunderstood something? How do you combine Scrum'ing an actual product with creating something reusable at the same time? Is reusability old-fashioned and overrated?
I would only spend the time building a generic graphing framework when you need to, for the first sprint write something that plots X versus Y. That might be as far as you go with graphing so there would be no need to write a framework.
If in further sprints you need to do more graphing, then create your framework. Work in time to the sprint to allow you to do this.
Generally if you create generic solution without actual need for it you are not following agile approach. You should avoid refactoring in advance. Otherwise it is gold plating where you are adding functionality which is not needed and which is not required by your customer at the moment (priority approach).
But sometimes it can be needed to create reusable component. This usually happens when more than one team plans to use the same component or when custom framework is created separately. In SCRUM you can do this in following approach. The main project which will use the component will become product owner for the component. It will define features which are needed as user stories. Component team will implement those features and provide the component to the main team in the iterative way.
So suppose that you have two projects which expects that they will need component for credit card payments. These two teams collect user stories with priorities and provides them to component team. They will plan together delivery so that component team provides only functionality needed by main teams in current sprint.
As Fermin says, the first time you need something isn't the time to start building a framework. YAGNI: you just build something that plots X vs Y.
Going further, I have found that even the second time you need something, it's still not time to build a framework yet. The problem with frameworks built on one or two use cases is that it's rare they'll actually be useful and generic enough for anything more than those one or two use-cases.
Building general, reusable, code is hard. There is nothing more useless and confusing to another developer coming after you than something that appears to be a framework, but is actually only used by one or two projects and is in fact tightly coupled with those projects.
One of the founding principles of the X Windows System was:
The only thing worse than generalizing from one example is generalizing from no examples at all.
Good advice I'd say!
I think the issues of reusability and code quality lie outside of the team process dimension. Well maybe not entirely, but at least the agile approach does not deal with those. You're free to put in some extra effort to increase the reusability ratio or just quickly hack things together.
You could add some extra fixed time to each sprint to be used explicitly for code review and working on reusability.