The Fuck

该文章发布在github中，如果您觉得写的还不错的话，可以 star 一下进行支持，传送门： TechShare 。 Bob 大叔在《代码整洁之道》一书的前言打趣着说，当你写的代码在经受代码审查时，如果审查者愤怒的吼道“What the fuck is this shit?”等言辞激烈的词语时，那说明你写的是 Bad Code；如果审查者只是漫不经心的吐出几个“What the fuck?”，那说明你写的是 Good Code。这就是衡量代码质量的唯一标准——每分钟骂出“What the fuck?”的频率。 想写出整洁的代码很难，有一部分原因在于糟糕的代码太容易编写。想快点完成任务时，考虑不周全时，忽略安全时，随意命名时，参数过多时，嵌套太深时，未及时更改注释时，违反法则时，重复你自己时等等情形，我们有太多的机会来制造糟糕的代码。只有严肃对待自己的代码，了解哪些事情会使我们的代码变味，才有可能写出整洁的代码。 写代码和写文章在某种程度上有相似之处，好的文章一定有好的可读性，写代码也一样，只有优美干净的代码才能具有良好的可读性。编写具有可读性的代码不光是保持有意义的命名就行，如果你想成为一名更好的程序员，写代码时你需要注意的有很多，比如： 规范本地变量的位置 使函数尽量短小 调用者尽可能放在被调用者上面 保持代码拥有良好的格式 编写只做一件事的函数 函数参数不要超过三个

转载自： https://zhuanlan.zhihu.com/p/58858217 另一篇参考文章，建议一起阅读，Python目录结构规范： https://www.cnblogs.com/endust/p/12304074.html 在我们团队，我们看到用python写代码的同学，他们的项目目录结构都非常乱，五花八门，每个同学都是随意的按照自己的喜好来创建文件夹，源码散落在这个文件夹中，很难看出代码的入口是在哪里。 JAVA有标准的maven目录结构，golang也有建议的目录结构，那么我想python是不是也有一个比较好的目录结构组织方式呢。我看了下几个比较流行的python开源项目。 flask requests thefuck compose tensorflow django 我也网上查了一下 best practice What is the best project structure for a Python application? stackoverflow.com 基本上可以归纳出一个比较大众的，符合开源社区习惯的目录结构: ├── README.md ├── docs ├── project │ ├── __init__.py │ ├── __main__.py │ ├── moduleA │ │ ├── __init__.py │ │ └──

参考http://www.manongjc.com/detail/6-kinpwythfvqzrth.html一文 Manjaro安装配置 1：换源 ： sudo pacman-mirrors -i -c China -m rank sudo pacman -Syy sudo vi /etc/pacman.conf 修改 /etc/pacman.conf ,在最后一行添加： [archlinuxcn] SigLevel = Optional TrustedOnly Server = https://mirrors.ustc.edu.cn/archlinuxcn/ $arch 安装archlinuxcn签名钥匙 sudo pacman -S archlinuxcn-keyring` sduo pacman -Syy 启动项： 　　 sudo update-grub 2：安装软件 ## 安装工具： sudo pacman -S yaourt ### Chrome浏览器： sudo pacman -S google-chrome ### 中文输入法： sudo pacman -S fcitx-im # 全部安装 sudo pacman -S fcitx-configtool # 图形化配置工具 sudo pacman -S fcitx-sogoupinyin 　　 一： 配置： vi ~

盲目自信，自认为已经敲了几年代码，还看什么整洁之道啊。我那可爱的书架读懂了我的心思，很明事理的保护起来这本小可爱，未曾让它与我牵手 最近项目中的 bug 有点多，改动代码十分吃力，每看一行代码都带一句“这是什么XX代码啊，真XX难改”，这样持续了好几天，有天晚上坐在书房回想这几天发生的一切，仰头定睛思考，我终于和它重新确认了眼神💗 股票见涨你知道买了, 汽车撞墙知道拐了, 孩子死了你来奶了, 大鼻涕到嘴你知道甩了, bug难改知道愤慨了 马上翻开书，前言章节，映入眼帘的就是下面这一张图 代码质量的唯一有效度量是：WTFs（what the fuck）/minute 真的太精辟了，这不就是这几天我白天经历的吗？代码已然是 bad code 了，我们应该怎么面对这种情况呢？ 每个公司的规范还不一样，本文是读书笔记，不会说明太多的代码规范，只是阐明我们应该怎样做或者抱着什么样的心态来写代码吧 如果你看到这里，我要引用书中的一句话： 第一，你是个程序员；第二；你想成为更好的程序员。我们需要更好的程序员 专业的态度 做国内项目/产品，通常都是指明deadline的，但是截止到deadline之前，需求量的多少是不固定的，说白了是“以deadline不变应需求万变”，美其名曰「敏捷」 我们经常要面对短期内开发出大量需求的请求，很可能为了快速完成这些需求，胡乱的堆叠代码