[bad practice?] Is this way of formatting code considered bad?

Hi all,

I’ve been formatting my function expressions and anonymous functions a bit differently than how they are usually presented everywhere (be it freeCodeCamp, books, websites etc.).

The reason I do this is because I find my way of formatting much easier to read but am concerned that by doing this I’m developing bad habits since I should really learn to read the code in the more conventional formatting.

Any feedback from the community would be greatly appreciated, thanks in advance.

The example I give below (no spoilers here) are from the starting code of " Write Arrow Functions with Parameters" in the ES6 part of the curriculum, link: https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/es6/write-arrow-functions-with-parameters

My preferred format:

var myConcat = function(arr1, arr2) {
                 return arr1.concat(arr2); // I like to indent here.
               };

console.log(myConcat([1, 2], [3, 4, 5]));

Usual format everywhere else (standard format):

var myConcat = function(arr1, arr2) {
  return arr1.concat(arr2);
};

console.log(myConcat([1, 2], [3, 4, 5]));

I see maybe one possible drawback to how I format the code, and that is the standard format is closer to how the arrow function looks (I stick to conventional formatting for arrow functions):

const profileUpdate = (profileData) => {
  const { name, age, nationality, location } = profileData;

}

So are there any drawbacks to how I format function expressions and anonymous functions? Should I just stick to conventional formatting? I guess ultimately what I want to know is, how come it seems no one formats it the way I like yet it seems much more readable?

Thanks everyone.

What happens when you need to nest again and you’re already ten characters in? Also, you’re going to get a ton of unnecessary line-wrapping, which will make your code harder to read in the long run.

2 Likes

Generally standard formatting is recommended.

On professional projects, there is usually a auto formatting tool.

2 Likes

@Salathor – Hey thanks for the quick response, appreciate it.

I don’t know why I didn’t think about further nesting :flushed: – so simple yet I overlooked this possibility…

It makes sense then to write it the conventional way. I guess from the examples I’ve come across so far, I just haven’t had situations where indenting the code made it more difficult to read but I agree with you.

Can I ask something else that is related but not exactly?

In the exercise “Use Arrow Functions to Write Concise Anonymous Functions” (link: https://www.freecodecamp.org/learn/javascript-algorithms-and-data-structures/es6/use-arrow-functions-to-write-concise-anonymous-functions) it gives this example at the very start (no spoilers):

const myFunc = function() {
  const myVar = "value";
  return myVar;
}

…and shows how ES6 provides us with the syntactic sugar to not have to write anonymous functions this way. Instead, you can use arrow function syntax (again no spoiler, this is example before the exercise):

const myFunc = () => {
  const myVar = "value";
  return myVar;
}

But I thought the example (before using arrow function), wasn’t an anonymous function because we are assigning the function (on the right) to a variable, which would make it a “function expression” instead. I thought an anonymous function is more like assigning the function (on the right) to something like window.onload.

Sorry if this seems trivial, it just helps me get my head around things when I’m crystal clear with what I’m working with. Any help would be greatly appreciated, thank you.

@JeremyLT – Thanks for your help, appreciate it.

I had a further question that I posted in my response to @Salathor , would you be able to provide any feedback on that too? Thanks in advance.

Someone else will probably be able to help better here. In my understanding, both are examples of anonymous functions. A function expression would be more like:

function someOperation(arg 1, arg2) {
  //do something
}

You don’t have to declare its name as a variable or constant.

2 Likes

Yes,

const myFunc = () => ...

and

const myFunc = myFunc() ...

are both anonymous functions that have references stored in a named variable. But the function itself is anonymous.


With regards to formatting, yes, standard formatting is best. True, there are a few variations, but indenting is generally bad.

As the old saying goes, you have to know the rules before you break them. Millions of coders coding for billions of hours have come up with certain principles. Unless you never ever want to code with other developers, it would be best to just learn standard practices. If you work on a project or at a company, you are almost certainly going to have a format decided for you and enforced by linters and prettier and such. You might as well get used to that now. And in the long run, you may grow to understand why.

1 Like

An arrow function is always an anonymous function expression.

Anonymous function expression (implicit name):

const fnExp = () => {
  console.log(fnExp.name); // fnExp
};

const fnExp = function() {
  console.log(fnExp.name); // fnExp
};

Named function expression (explicit name):

const fnExp = function namedFn() {
  console.log(namedFn.name);  // namedFn
  console.log(fnExp.name);  // namedFn
};

Function declaration:

function fnExp() {
  console.log(fnExp.name); // fnExp
}

As for formatting, I would suggest you do not invent your own best practices. The point of consistent formatting is that everyone writes and reads the same formatting.

It is a lot like the location of objects in the real world. You can open a door with your eyes closed because you know where the doorknob is going to be.

3 Likes

@Salathor – thanks, appreciate the response.

@kevinSmith – hey, thanks for the response, appreciate it.

Okay that makes sense, for some reason I thought any function, if we store it in a named variable, then that function is not anonymous (because we can then call that variable like a function). But what you’re saying makes sense, the function itself is anonymous.

As for formatting rules, yeah I do stick to conventional formatting in all cases but made an exception for that one case, but you make a strong case not to do that.

At first I thought indenting the code was somewhat akin to having “training wheels” and that it was okay in the beginning since I’m new to programming. I’ve also been indenting that part of the code in my notes. But I’ll stop doing that now, given all the drawbacks you and others have pointed out. Thanks again for the comment.

@lasjorg - hey, thanks for the response and the examples you gave are clear.

I actually didn’t realize it was possible to have a named function expression (explicit name). I don’t think I’ve seen it before.

From the MDN link you provided regarding function expressions, this is clear:

A function expression is very similar to and has almost the same syntax as a function declaration (see function statement for details). The main difference between a function expression and a function declaration is the function name, which can be omitted in function expressions to create anonymous functions.

This makes sense and from reading this I see that anonymous functions (i.e., function expressions with no function name) are anonymous regardless of whether they are assigned to a variable – as in the first example you gave and others have pointed out too, thanks again.

As for formatting, you’re right, it makes sense to stick to convention. I’ve always followed standard formatting rules in all other cases and only indented it differently for that one case, but going forward I’ll definitely stop doing that, for reasons you and others have pointed out.

Thanks again for the response.

It would be like if you met someone with amnesia and gave them a name tag that says, “Clarence”. Everyone can refer to that person as that and everyone knows what it means, but that person still doesn’t have a “real” name.

1 Like

No, it’s not training wheels, it’s very important. Code is confusing stuff.

Readability is hugely important in code, on all levels. HUGELY! Imagine having to read throw 5k lines of code to find a bug - anything that helps you read is a good thing. Anything that slows you down is bad. Even 1/10th of a second can add up over and over.

And all those spaces/tabs get removed when the code is compiled/bundled/build, so don’t worry about it.

2 Likes

@kevinSmith

Wow, great analogy, thanks!

Yeah a lot of this stuff is completely new to me, so still trying to get my head around things.

Right now what I do is when I’m making notes, I often print out the code and use different color pens and underline or draw boxes around certain bits of code. I kind of have a color system so that I can identify parts of the code easily at a glance.

But I do know that in the long run it’s not feasible to be printing out code (let alone marking them up with different colors). Instead I’ll have to stick to just leaving comments in code. But for now I’m still struggling with being able to read code, so like you said, readability to super important!

Thanks again for the comments.

Well, and don’t forget–it’s still indented. It’s just indented in a certain way. You just need to take the time to learn how to read/parse standard indentation.

And then maybe you can tell me why they like spaces instead of tabs for indents, which I still don’t understand.

1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.