关于vue组件内部命名规范的一些思考和意见

开局感慨一下，一转眼玩vue已经三年了。平时都是搬砖搬砖搬砖。。。死循环那种。很少写博客，因为我觉得好像没啥好写的，官方文档写的清清楚楚，明明白白。工作中遇到的问题，大部分在官方文档里能找到答案，如果你不知道，那说明你没有认真看文档，或者看得不仔细！剩下的小部分，文档中找不到的，百度谷歌一定有。咱们都是新人，这行发展这么多年了，你要相信你遇到的问题，早有无数前辈踩过了。em。。。啰嗦了，跑题了！咳咳
那么，开始今天的主题吧！
玩了这么久，代码撸了也有不少了，别人的同事的代码也看过不少。每次遇到bug，自己写的还好，找起来得心应手（找不到的都不是我的代码，小声哔哔）。但也有的时候，会有比较大的组件，代码一多起来，命名就有点蛋疼，都懂的。。。这个时候找起来就，比较坑了！跟别说，要是别人的代码，或者已经离开的同事的代码，那就真的好嗨哟！也许有的朋友，这个时候，就会提示我ctrl+f。嗯，没错，这是个好方法，非常好用（真的）！的确，它能找到你想要找到的任何东西。但是，在一些特殊情况，它能找到，可是却无法帮我们快速定位问题。
举个很简单的例子

这段代码，很简单。里面有个msg属性，一眼就能找到。我们要使用他的时候只需要：

this.msg;

这很方便，很好用！niu b。。。
但是就是这种方便，也给我们带来了隐患。大家都知道this是这个组件的实例对象，this下面挂载了很多东西，不仅仅是data里面的属性可以这么拿到，methods里定义的方法也可以直接调用，computed和props也可以。那么问题就来了，当组件代码量足够大的时候，我们无法很快的定位this后面属性的来源。

// 还是上面那个例子
this.msg;
// 你没法在看到这行代码的时候，就能很清楚的知道，这个msg是props里的还是data或者
// computed中的，甚至它可能是一个函数！

这对我们阅读代码，特别是阅读别人的代码，非常不友好。极大的拖慢了排查问题，和修复问题的成本。
那么我们改如何解决这个问题呢？结合我自己的和同事的想法，大致整理了一下。也没有太好的方法，只想到了给变量加上标识（类似命名空间）。
还是上面那个例子：

通的msg我们给他加上一个前缀，很清楚明了，不管你再什么地方，看到它，就能知道她是哪里来的，还有做替换的时候也将会非常方便。不用担心弄错。
当然这里只是举个例子，如果觉得这个前缀太长或者不好看，也可以自己定义规则，这个看个人和团队。
比如：
props：p_msg
data：d_msg
computed：c_msg
methods：m_msg
这只是一个不成熟的想法，如果大家有别的更好的办法，欢迎讨论！

最后分享一个vue组件的模板，希望对大家有用：