我的天

以前写网页，都是在记事本里，一个一个字敲。缩进什么的，通常都是用tab完成，因为如果要敲4个空格键，实在太难了，而且那时我也不知道标准做法是4个空格键。我不可能每次都那么准确敲4个空格，如果敲漏了可能就会对不准，会逼死强迫症。我已经不记得以前我是怎么保证那些需要成对出现的东西配对的，所有东西对我来说都像是白纸黑字，所以在记事本里敲跟我在白纸上面写没什么区别。

很多年以后，我开始用Notepad++，那个东西的好处是会根据不同编程语言把标识符都给高亮出来。很智能的地方还有显示到底我配对的是哪一层，这样就让我在查找问题的时候简便了很多。但到这里为止，我做的所有事情也都只是在靠着自己的眼力去完成。

再到后来，当我已经不再设计自己blog网站之后，准确来说，是当我下定决心，要用python去解决blog导出数据转换的时候，我用上了vscode。我使用vscode的时间跟我系统学习python的时间是一致的。一边学习python，一边在vscode里实践。那是我第一次用上那么智能的编辑器。有了那个东西以后，如果我犯了一些低级的错误，马上会有红色波浪线给我标出来，如果有一些可能错，但未必一定是错的东西，就会给我标黄。所以如果我遇到的那些东西，基本上我就不用测试程序了，肯定不会通过的，但即便没有被波浪线，也没有被标黄，测试的时候可能依然得不到我想要的效果，但有时会给我提醒到底是哪一行、运行到什么情况的时候不对劲了。

学习过C，研究过html，也玩过php，去年也着用了office里面的VBA。我觉得就思路呈现而言，python是让我觉得最自由的。因为没有那么多条条框框的格式限制，甚至连配对的括号都不需要，只需要要恰当的缩进就能解决问题。在vscode里，标准的缩进使用4个空格，但你也可以用tab。同时你也可以设定把tab自动转化为4个空格。有了这么方便的缩进。python那些必须用缩进说明层次的问题，完全不是问题。

这一次，当我要做级联下拉网站的时候，我在vscode里写html。在标签配对方面，感觉实在太爽了，标签会自动给我匹配，缩进也会给我自动实现。在写ID、写class的时候，可能会空格乱写，但只要全选之后，Shift+Alt+F就可以做一个格式化。格式化以后，所有东西都是完美的。有时我要引用某个js或者css。引用的不是一个网站链接，而是某层文件夹里面的东西，那个时候vscode把理论上我应该全部敲出来的东西给我变成了下拉的选择题。这些选择题，在我敲打标识符的时候也通常很自然地带出来。标识符这个玩意，在编辑器里，有些会自动带出来，有些不会。不会的时候，非常有可能你脑子里想到的是某个东西，但你手上敲出来却是另外一个玩意，于是就会导致最后完蛋了。让我觉得爽的还有vscode的高亮是我喜欢的那种颜色。以至于习惯了vscode的暗黑配色以后，我把Notepad++的主题颜色也变成了高仿vscode的样式。

以前写网页是因为我要写，现在有了vscode的加持，我觉得我可以写得很舒服。

Excel的一般公式，我比较熟练，一些高级公式的叠加，我需要找教程套用，但起码我知道那是可以做到的。一般的数据透视表，是我一直以来用得相对来说最顺溜的东西，至于高级的数据透视表，也就是超级数据透视表我几乎不了解它的高级用法。在数据的筛选查询方面，之前我用的是公式，而近期，我知道了有Power Query这种神器。在这之前，我已经知道可以SQL语言查询。去年我开始系统学习了Excel VBA。这让我大大提升了某些工作的效率。当然这是非常有针对性的。对我来说，要开发一个VBA脚本需要好些时间，并不是一写就能用的那种类型，期间要经过不少修改。所以其实总的来说，对Excel的了解我还是比较全面的。

也正是因为有这样的经历，所以当我遇到某些综合性的问题的时候，当别人把目光主要集中在某个他们很熟悉的版块的时候，我会凭借我的直觉找问题，而不局限于他们觉得出问题的那个地方。比如在把SQL查询跟VBA结合的时候，别人会把精力放在SQL查询有没有写错上面。SQL有没有写错，其实我根本没看，对我来说那些东西太长了，看不懂，而且那个人写的VBA脚本缩进很有问题，看得我很郁闷，所以我就更加没有心情在那里琢磨。那既然能计算出一个正确答案，说明那个查询语句应该没什么问题。也正是因为写脚本的人的那堆东西格式比较混乱，所以我有理由怀疑那是拼凑起来的脚本，因为居然在脚本的开头连变量的定义都没有。为什么VBA里没有进行规范的变量定义，后面也居然可以照样使用呢？这让我有点惊讶，毕竟这是个VBA，不是python。C语言里，如果不先进性变量定义，后面根本用不了。在我记忆之中，VBA的变量在使用之前是需要先定义的。最终我发现是那个人的脚本之所以出错，是因为某些语句的套用搞错了，为什么他会把那个东西放在里？我觉得大概是因为他没有明白他一开始做的那个with是什么意思。但如果你问我为什么他把那堆东西套在里面会出错，而且是某些地方出错，不是全部出错，我回答不出来。理论上这种错误能在恰当的调试中体现出来，但实际上，VBA的调试句子我还用得不算很熟练。或者你会说，这是因为我的VBA学习还不够系统化，但我觉得我已经用了学习VBA最靠谱的那本书了。可以肯定的是，一些很基础的调试方式我还没掌握，如果我学会了那些东西，我可以大大提升我的调试效率，把错误定位得更精准。VBA脚本这种东西，我觉得最根本的是必须得理解。如果纯粹是各种套用，基础功能的确可以快速实现，但是当遇到的问题比较综合的时候，就会出现一些他们完全料想不到的状况。那种状况有可能与脚本本身的内容无关，与脚本的结构有关。

相对来说，Excel里我用得最弱的是高级公式的套用。如何用一个非常复杂的公式解决一些高端的问题是我一直以来都不大上心，或者说记得不够好的部分。非常复杂的公式，尤其是数组公式，虽然能解决一些神一般的问题，但问题是，其实那些公式需要耗费大量资源，所以在处理大数据的时候，非常有可能出状况。我是一个实用主义者，能做到某个功能，但是做起来的效率不高不好，我为什么要选择那种只是看上去很炫酷的方式呢？情况就像用VBA解决同一问题的时候，如果只是在工作表层面处理和先用内存数组处理再在工作表层面表达，效率千差万别。

Excel对我来说，除了要最终结果，过程也得追求高效和方便。

昨天我实现了前天还不能实现的功能，用起来果然很爽。Power Query拯救了用vlookup公式导致源数据界面输入卡顿的问题。关于vlookup的卡机，据说用Power Query或者Power Pivot都能实现，而且据说PP的效率比PQ还要高。PQ现在我知道应该在哪里写代码了，但PP的DAX到底在哪里写，至今我还没找到。相对来说，我觉得PQ界面的按钮多一些。PP的按钮感觉跟数据透视表很类似。这就意味着，厉害的功能就隐藏在普通的东西之中。PP跟PQ比起来，函数的数量少了很多。用过的人都说，PP要比PQ简单，PQ就像一个谜一样。

前几天当我搜索，PQ教程的时候，发现了里面居然有递归。在谈递归的时候，把迭代也放进去了。迭代跟递归有什么区别现在我还不知道，但我知道递归和循环有什么区别。当某个函数的控制可以把判断和循环都用上的话。再加上700多个已经事先设定好的系统函数。PQ要实现一些神一般的功能显然是理所当然的。只有你想不到，没有它做不到，但前提是，要做到某些功能，光靠可视化版面，根本不可能。要在高级编辑器里自行折腾，或者在自定义的地方选择性折腾。光靠鼠标点击按钮是没办法把PQ的函数层层套用的，没办法一次性套用多个函数，某些功能就比较难实现了。对小白来说，要掌握所有可视化的按钮，尚且没那么容易，但是真正的高手，是必须自己写码的。

PQ用的是M语言，貌似我在VSCode的插件里面没找到相关的东西。里面有DAX的插件，可以自动补全和语法高亮。M语言更需要这种插件，因为光是函数的大小写就会把人搞疯掉。英语输入默认全部都是半角，但是如果我们的脚本里面还有中文，那就意味着中文跟英文得不断切换。光是逗号这种东西就会搞死人。而且我们的脚本里面，还不可能不出现中文。的确，函数可以起英文名字，但是，要处理的数据的列名，必然有中文，因为表格的内容有中文。我不知道那些写码的人是如何克服这种中文英文切换标点符号的问题，反正我是觉得，双引号，逗号，小括号这种东西经常让我很烦恼。不过幸好，据说，Office 2016以后的PQ，在写码的时候有自动补全功能，的确现在我的Microsoft 365可以这样，不仅仅是函数可以自动补全，连变量也可以自动补全。我不知道其他人写码的时候是怎样的，反正自从我习惯了python以后，我实在不能接受没有规范缩进的脚本。也正是因为有了python的习惯，所以我也默认把缩进从tab换成了4个空格。习惯了在VSCode里4个空格是4个圆点，现在PQ里没有这种东西。总让我觉得很不智能。

所有office文件都可以修改后缀，变成一个压缩文件。里面你看得懂或者看不懂的东西实际上就是数据以及你执行的步骤，所以PQ虽然有可视化界面，但实际上，它的高级编辑器让我觉得，那东西还原出了office软件数据处理的本身。

今年我的计划是学R语言，但实际上，我迷上了python，接着现在，我又迷上了M语言。

昨天晚上，在做那些文字游戏的时候，我做到了好像怎么费劲就轻而易举地把题目做出来了，只需要几分钟到十几分钟。从写脚本到测试成功，整个过程没有状况，甚至写完脚本后，所有东西下面红色波浪线都没有。通常，我都会习惯忘记在句子的结束加上冒号。Python要求必须严格缩进，多了少了都不行，而且使用缩进必须用一样的方式，通常必须要求用4个空格。习惯了用VSCode以后，我会设置缩进为4个空格，当我在上一行回车之后，如果上面是冒号，下一行就会自动缩进4个空格。但如果某段代码不是我写的，而是从某个地方复制过来的，就可能会出现状况。所以为了避免这种无聊的出错，我把所有占位符都显示出来。比如空格，也比如tab。大概对其他人来说，写代码就应该是行云流水的。知道自己要实现的功能是什么，知道自己应该用什么方法，然后按照思路按部就班。调试这种东西没有个尽头，没有说用了某些方法测试就能一定保证调试完以后程序没有任何的bug。只能做到尽可能少bug，不可能做到完全没有bug。不知道从什么时候开始，我觉得不把话说死非常重要。

昨天我终于体验到云流水般写代码，是因为在行云流水之前我已经纠结过好几个小时。在行云流水之后，我也遇到了命令行的光标卡在那里，不显示程序有错误，但是程序也不进行下去。如果我进入了死循环，程序出不来，Python会提示我上面已经进行了超过994行，别浪浪费大家精力了。之前我已经见识过了。而昨晚我遇到的是光标停在那里，没有任何提示。脚本那里也没有任何红色波浪线，说明语法是对的，起码静态语法没问题。当我再次看到脚本的时候，发现原来是我在用while进行循环迭代的时候，没有设置改变条件的东西，于是while的循环就停在那里了。在我构想那个循环的时候，其实我是设定好增量条件的。我的脑子已经准备好了，但我的手指并没有把增量条件敲上去，所以就出现了之前死在了终端的状况。我不知道光标死在了终端我还能做些什么，反正我的处理方式是把终端关了。光标停在那里，输入什么都没有反应，又或许如果我在单独的CMD命令行里搞那个的话，我可以用某些什么方式从那里跳出来。只是我现在不知道该做些什么。因为我是在VScode的测试，所以我简单地把那个终端的窗口关掉，重开一个就好。

还记得，在大学里学习C语言的时候，其实我不怎么喜欢用while这个东西循环，我更喜欢用for。拿Python跟C语言比，我觉得后者需要我们在写代码的时候更加仔细严谨。比如花括号这种东西绝对不能省。也比如某个对象在使用之前必须先声明，不只要说明它存在，而且要确定好那是一个什么类型的东西。在循环控制方面，C语言一开始就必须得想好所有。相对而言，Python很自由。昨天我突然发现原来in这个东西可以让if这种语句也具备循环的功能。在实现某个功能的时候，我用了两个for嵌套，而参考答案只用了一个for和一个if，出来的结果完全是一样的。我在两个for里还得加个if做判断，相对参考答案而言，显然就有点臃肿了。

我明明知道做习题会让我死去活来，但是一定程度上，我却在享受那种征服未知的刺激。