-4

Let's get to an example. Suppose, I have a Course object with the following properties: (course' code, course's title, credit of course etc.). When expressing this as a JS object, I can do it in the following ways:

1.

const course = {
    course_code: 'CSE123',
    course_title: 'An example title',
    course_credit: 4
}

2.

const course = {
    code: 'CSE123',
    title: 'An example title',
    credit: 4
}

Pro of Option 1 to me seems that it's easy to understand what object's properties are being accessed just by looking at the property name. But its quite verbose

But Option 2 is less verbose and avoids repeating the same thing.

What are the conventions regarding this? I would love some resources on this.

| improve this question | |
4

You don't have to prefix the property name with the object name. The object is the main entity and properties you define is it's attributes. So for example if you have object as

const course = {
    code: 'CSE123',
    title: 'An example title',
    credit: 4
}

You will access this as course.code, course.title etc. By looking at this you can easily understand that code belongs to the course and same for title.

You don't really have to use course_code, course_title. I hope this helps.

| improve this answer | |
2

Your course is already named course in your source, so it's not worth it to read and write course.course. That is, of course, unless those course_ keys might move to another set.

For example let's say that for some given course we merge it with data called advisorReport, to produce a result the reader consults like:

{ course_code: 'CSE123', ... advisor_comments: '10/10, I endorse' }

This example is pretty contrived of course - and you'd only do it when your hand's being forced - but there might be a day when your keys are divorced from the object whose name gave them sense.

ES6 destructuring assignment can set the names of some vars (or some consts or some lets) directly from keys of an object it gets using code that looks something like this:

const { code, title, credit } = course
const { comments } = advisorReport

The code, title, and credit are set from the course, and the comments came from the advisorReport, but now in the course of re-reading your source you are forced to remember this fact.

Coder memory is of course the most precious resource, so to reduce the number of items it stores, when you find that your keys get divorced from their source you can make them a bit more verbose.

| improve this answer | |
  • Though I don't personally like to use it this way, ES6 destructuring allows you to rename properties on the fly if you really need to: const { code: course_code } = course would give you the course's code as course_code. – Jacob Raihle Jul 10 at 22:44
  • @JacobRaihle I agree that's better to rename it right there, so you don't have to later be wondering where these verbose object keys like advisor_degrees, will eventually get actually used. – Luke Griffiths Jul 10 at 22:51
  • Less verbose key names with ES6 destructure+rename seems to be the best of both worlds. Thanks for the suggestions. – Jahirul Islam Jul 11 at 17:25
1

In case one,It is a violation of coding standards,which means it's not a good way for coding for accessing code from couses you will need to write course.course_code which does not look good.

Most preferred way is case two,as per Manoj explained in above his answer and developer who is accessing the code from courses will know its from couses because its is addressed as Courses.code.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.