# FAQ: Code Challenges: JavaScript Fundamentals - tipCalculator()

I learned from your previous post so I could code in the following way

``````const tipCalculator = (quality, total) => {
return quality === 'bad' ? total * 0.05 :
quality === 'ok' ? total * 0.15 :
quality === 'good' ? total * 0.2 :
quality === 'excellent' ? total * 0.3 : total * 0.18;
}
``````

Now I learned another trick from you and this object lookup solution looks much more scalable and easier to maintain. Thank you @mtf

1 Like

How is this scalable? I don’t see how this has anything to do with scalability

Nested ternary operators are actually a no-go when it comes to maintainability and readability

By ‘scalable’ I was referring to @mtf 's solution using object lookup. Sorry for the confusion.

1 Like

Hi team, I tried making the tipCalculator using a switch statement. I keep getting “Unexpected token errors” and do not know what I’m doing wrong:

``````const tipCalculator = (quality, cost) => {

// Compiles cost + percentage
let compiled

switch(quality) {
compiled =  cost + 5%;
break;
case 'ok':
compiled = cost + 15%;
break;
case 'good':
compiled = cost + 20%;
break;
case 'excellent':
compiled = cost + 30%;
break;
default:
compiled = cost + 18%;
}

let tip = compiled - cost;
return tip;
}
``````

This might make sense to you, but the computer has no idea what to do here. The `%` symbol is used for modulo operations, so it is expecting that another number comes afterward. Rather there’s a semicolon there, causing the `Unexpected token error`.

How should we be calculating 5% of the cost? Simply doing `+ 5%` won’t work. Firstly, 5% of what? We need to specify what we want to take 5% of. Secondly, since we can’t use `%` to denote percentages as the symbol is the modulo operator, how else can we write an expression to get 5% of the cost?

tipCalculator

When running the code it brings back the right numbers to each argument but the exercise is still marked as wrong, see the message saying “when tip is ‘bad’ it should return 5.”
But when running it actually returns 5

Does your function return anything? We cannot tell from the image.

Thanks for getting back.
It was returning the right numbers.
However I changed my code for every switch case, I was calculating porcentage like this (30/total) * 100
and changed it to total * 0.30 and it was accepted .
I am still not sure if that was the reason, I am not entirely sure why it didn’t like the other way, maybe wasn’t the clearest code?

The lesson checker is not very exhaustive, and sometimes even arbitrarily simplistic. Nonetheless, you did find a workaround that didn’t cut any corners and is not a hack. Well done on the adjustment.

1 Like

//My code calculates 5% for all entries. Why?

Remember that we use `=` (the assignment operator) to assign values to variables. We use `===` (the strict equality operator) to check for equality in values (and in type).

Aside: if you don’t need to use `result`, there’s no need to declare it.

Yes! Thank you. Fixed it and it works

1 Like

I have a question. This code works and passes the tests and as far as readability I’m pleased with the result. However, being the first time I’ve dropped the use of curly brackets in an else-if (within an arrow function) I am concerned if this is proper formatting or if doing so sets me up for problems down the line that may not present in early stages like this?

const tipCalculator= (quality, total) => { if (quality === 'bad') return .05 * total; else if (quality === 'ok') return .15 * total; else if (quality === 'good') return .20 * total; else if (quality === 'excellent') return .30 * total; else return .18 * total; }; console.log(tipCalculator('good', 100))

Many or most organizations use a style guide which may recommend against that style of coding. JS permits us to drop the body wrapper if there is only one statement, such as ‘return’.

1 Like

So any issue would stem more from consistency of style vs the code itself causing issues down the line?

This is really good to know! Right now I’m just doing this for my own edification so I’m trying to make things readable to me. However, I understand the (extreme) importance of needing to adhere to style guides when working with a group.

Thank you!

1 Like

Future proofing our code is an underlying concern. What happens if a later iteration of the language stops supporting our more concise style? While this is probably not likely since JS tries to be backward compatible, that is not carved in stone.

One check would also be to see how the code behaves in Strict mode.

1 Like