（预先说明，我下面的回答主要是考虑到面向初学者的一些思路性的说明，因此请各路大神不要来纠缠我说的不够全面之类的，太全面了初学者也消化不了）
嗯，你这个问题其实可以引申到所有的编程活动中去，一个初学者，如何判断自己的代码究竟是好还是不好，如果把代码的味道从0分到10分来打分的话，又应该打几分？
首先，关于什么是好代码，在很多时候是有争议的，大多数语言社区都有好几个同时流行的代码风格，然后在一些细节上，更是分歧无数，因此一段代码，给A看，可能打9分，给B看，可能就只能打8分了。
那么，是不是就完全没法判断了呢？答案是否定的，如上的例子，虽然A和B会给出不同的分数，但我相信A只打5分的代码，B绝对不会给到6分以上。基本上来说，对代码味道的分歧，基本上只会在8分以上的代码中才有意义。
那么，怎么判断呢？说细了，可以写出一篇大论文来，但简单的说，其实主要就是两个标准：
可读性与可维护性
应对变化的能力（叫啥性来着？脑袋卡住了想不出这个词来了。。。）
就第一条来说，并不是说可读性高容易读懂的代码就一定好维护，但反过来，好维护的代码一定是容易读懂的，谁都读不懂的代码谁也没法维护不是？至于如何提高可读性，如何提高可维护性，我这里懒得展开了，大把的文章在谈这个。初学者囿于能力，的确经常很难写出足够可读的代码，我曾经有好几次将手下写的洋洋洒洒几百行的代码清理成二三十行简单代码的事情，这个一方面取决与经验的积累，另一方面，其实也是工作态度的问题，当你用几百行代码解决了一个问题之后，你有没有回过头再想一遍，你是不是把问题想复杂了？就我个人来说其实也是一样，在解决某个不熟悉的问题的时候，刚开始可能会脑洞大开，洋洋洒洒写下好几百上千的代码，但真的完成之后，自己对这个问题从整体上有了更好的把握之后，通常第二步就是着手简化代码。而对于熟悉的问题，通常来说，那洋洋洒洒几百行代码会先在脑海里一闪而过，等打开编辑器开写的时候，就可以直接从第二步开始简化代码了。
第二条，应对变化的能力，这个是初学者最难把握的，因为就可读性来说，老实说，初学者真要写出很复杂的代码后，他自己多半也是清楚的，虽然没有能力将代码简化，但“代码很复杂”这个认识一般还是有的，但应对变化的能力，这个很多时候其实跟经验有关的，对于有经验的开发者来说，很容易预见到代码将来可能的发展方向并预先做一些准备，并且，很容易在预先做准备与开发成本之间找到合理的平衡点。但对初学者来说，首先最大的挑战就是，我怎么知道这个代码将来会变成什么样子？其次就是如何在应对变化和现实的开发成本之间取得最优的平衡。这个一方面是经验的积累，另一方面，其实也还是取决于你的想象力，你要在编程的过程中不停的问自己，这个需求会不会变化，我将这个变量声明成整数，将来有没有可能它会在业务上需要用一个字符串来代表？我在这里声明了一个数组，将来有没有可能这个数组会变得很大，因此内存会不够？哦，就题主说的前端的代码，可以举一个初学者常见的错误来解释你应该如何想象你的代码，比如你定义了一个css class名字叫red-ttile，作用是将标体的字体颜色设为红色，当你写下red-title的时候，你就应该问自己，将来我会不会需要将title的字体变成绿色？是到时候将red-title改成green-title好还是一开始就不要将颜色定义到class name上去。这个例子很浅显，大多数教授css的教材也都会强调这一点，要面向业务对象定义类名而不是实际的式样来定义，理由就是我这里提到的，应对变化的能力了。
最后的结论就是，对于初学者来说，如何判断自己的代码写的好不好呢？第一，反复的问自己，有没有更简单的办法？第二，开脑洞，想象一下你的需求变更后你的代码怎样才能跟上形势。