前言在 Python 中，数据容器是组织和管理数据的重要工具，集合作为其中一种基本的数据结构，具有独特的特性和广泛的应用。本章详细介绍了集合的定义、常用操作以及遍历方法。...元素2，元素3，元素4，…}定义空元组：变量名称 =set()②特点：可容纳多个数据可容纳不同类型的数据（混装）可修改（增加或删除元素等）数据是无序存储的（不支持下标索引）不允许重复数据存在支持for循坏...，不支持while循坏# 定义集合my_set={"A","B","C","B","A"}# 定义一个空集合my_set_empty=set()print(f"my_set的内容为{my_set}，类型是...for循坏遍历:# 集合的遍历# 集合不支持下标索引，所以不能用while循坏，可用for循坏set1={1,2,3}for element in set1: print(f"集合的元素有{element..., 'best']# 定义一个空集合my_set=set()# 通过for循坏遍历列表for element in my_list: # 在for循坏中将列表元素添加至集合 my_set.add
while循坏: for循环: while和for循环的对比: 区别:for 和 while 在实现循环的过程中都有初始化、判断、调整这三个部分，但是 for 循环的三个部 分⾮常集中，便于代码的维护...main() { int i = 1; for(i=1; i<=10; i++) { if(i == 5) break; printf("%d ", i); } return 0; } 运行结果...: continue:跳过本次循.环中 continue 后的代码，直接去到循环的调整部分。...; i++) { if(i == 5) continue;//这⾥continue跳过了后边的打印，来到了i++的调整部分 printf("%d ", i); } return 0; } 运行结果...: 对比for循环和while循环中continue对代码的运行影响: 分析代码可以知道它们修改条件的位置不同 对于while循环的修改条件在continue后面所以当i=5时,他没法继续修改,而是陷入
如果你忘了在某个地方进行修改，或者对不同副本进行了不同的修改，程序可能就会出错。重复代码长期维护来说是一种噩梦。...3、注释掉的代码和死代码 注释过的代码和死代码都是代码的坏味道，因为它们会形成误导，让程序员认为这些代码是程序的可执行部分。...4、打印调试 打印调试是指在程序中临时调用print()显示变量的值，然后重新运行程序的做法。很多人误认为打印调试快速简单，但实际上为了获得用以修复错误的信息，通常需要多次重复运行程序。...优化坏味道的方法 1、重复代码 解决重复代码的方法是去重，简单地说，通过把代码放在一个函数或者循环中，使其在代码中只出现一次。 2、魔数 解决方法是使用常量替代魔数。...6、嵌套列表解析式 最好的办法是把列表解析式扩展到一个或者多个for循环中。 最后，我们要正视代码的坏味道，有些代码的坏味道根本不是真正的坏味道。
一、注释 不要给不好的名字加注释，一个好的名字比好的注释更重要； 不要“拐杖注释”，好代码 > 坏代码 + 好注释； 在文件/类级别使用全局注释来解释所有部分如何工作； 一定要给常量加注释； 团队统一定义标记...： 不恰当的信息； 废弃的注释； 冗余注释； 糟糕的注释； 注释掉的代码； 唯一真正好的注释是你想办法不去写的注释： 不要有循规式注释，比如setter/getter注释； 不要添加日志式注释，比如修改时间等信息...某个公共函数调用的私有函数紧随其后； 最理想的参数是零参数，最长不要超过三个入参，尽量不要输出参数： 如果函数传入三个及以上参数最好将其抽象为类； 标识参数十分丑陋，向函数传入布尔值用于区分不同业务的做法很丑陋...； 经常性地通读标准库的整个API，保持对他们的熟悉程度； 简单设计： 运行所有测试； 不可重复； 表达了程序员的意图； 尽可能减少类和方法的数量； 以上规则按重要程度排列； 无论是设计系统或者单独模块...，别忘了使用大概可工作的最简单方案； 整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。
(2)当你写单元测试的时候，是不是发现很多代码无法测试？...(3)是不是对重构没信心？这个话题太老生常谈了，配备有价值的、高覆盖率的单元测试可解决此问题。 (4)当你在写Android代码（比如网络请求和DB操作）的时候，是如何测试的？...关于第二个问题，己所不欲勿施于人 我始终觉得让QA写UT，是一种傻叉的行为。单元测试是一种白盒测试，本来就是开发分内之事，难道让QA去阅读你恶心的充满坏味道的代码，然后硬着头皮写出UT？...这种做法不仅仅可以在写UT的过程中使用，在开发过程中也可以使用，当服务端的接口开发滞后于客户端的进度时，可以先约定好数据格式，客户端采用模拟网络请求的方式进行开发，此时两个端可以做到不互相依赖。...网络请求的异步回调如何进行测试 关于网络请求之后的回调函数如何测试，笔者暂时也没有什么自己觉得满意的解决方案，这里提供一种做法，权当抛砖引玉，希望有此经验的人提供更多的思路。
在数学中，我们需要用到很多求和的办法，比如说求1至100的和，还有100以内的所有偶数和和所有奇数和，如果我们慢慢地计算是不是很浪费时间，还容易出错。...代码运行效果： 方法二：for循坏 count = 0 for number in range(100): if number % 2 == 0: continue...： 方法三：while循坏 count = 0 number = 1 while number < 100: count += number number += 2 print...: count = sum(x + 2) return x + count print(sum(1)) 先看下什么是递归： 递归（Recursion）递归是一种解决问题的思路...，其精髓在于将问题分解为规模更小的相同问题，直到问题规模小到可以用非常简单直接的方式来解决，其算法方面的明显特征就是：在算法流程中调用自身。
标识符可以包含 英文、0-9数字、$、下划线 不能以数字开头 不能有关键字 建议命名方式 首字母大写、后面每个单词的首字母都大写 首字母小写，后面每个单词的首字母都大写 方法名：同变量名 常量 常量：在程序运行期间固定不变的量...自增自减运算符：++、– 基本含义：让一个变量涨一个数字1，或者让一个变量降一个数字1....，一般可以分成四部分 初始化语句：在循坏开始最初执行，而且只做唯一一次 条件判断：如果成立，则循坏继续，不成立循坏退出 循坏体：重复做的事情内容，若干行语句 步进语句：每次循坏之后要进行的扫尾工作，每次循坏结束都要这样...for循坏 while循坏 标准格式 while(条件判断){ 循坏体 } 先执行初始表达式，看布尔表达式，满足就执行循坏体跟步进表达式 do while 初始化语句...do{ 循坏体 }while(条件判断); 求100里的偶数和 装了个notpad++感觉还可以的，写中文终于不乱码了 三大循坏的区别 循坏控制 break语句
如果不做这个校验，是不是我也可以正常在子线程更新UI 但是google为什么要这样去设计呢 ViewRootImp是在onActivityCreated方法后面创建的吗 为什么一定需要checkThread...为什么还需要开启消息循坏 使用子线程更新UI有实际应用场景吗 Android为什么不能在子线程更新UI？ // Android中为什么子线程不能更新UI？...则会抛出异常 如果不做这个校验，是不是我也可以正常在子线程更新UI // 如果不做这个校验，是不是我也可以正常在子线程更新UI？...为什么还需要开启消息循坏 // 保证上述条件1成立，不就可以避免checkThread时候抛出异常了吗？为什么还需要开启消息循坏？...条件 2 可以让更新的 UI 效果呈现出来。
好，本节的主题是：单元测试。 测试其实分很多种，就我在企业中的认识，一般称为测试工程师，从事的应该是所谓的集成测试(或者说是 AC测试（Acceptance Criteria，验收准则）)。...我讲其中的一种吧。比如微服务领域，大多数服务其实是RESTful API 的形式。如何进行功能测试？...即你提交代码，自动会触发UT, 运行程序内的单元测试，单元测试之后有一定的质量统计，比如覆盖率，一般的大厂的代码覆盖了阈值是90%, 即提交代码，UT 运行之后，代码的覆盖率达到 90% 才可以合入。...编写一个测试，再写函数，直到测试通过，如此循坏。...(当然实际上测试驱动开发，真正实施还是略微有点困难，一般的做法都是开发、测试，而不是测试、开发、测试、开发) 一般的初学者，是不太会关注测试，在没有进入职场之前，我甚至完全没关注测试，直到走入职场...
它是一种简单的排序算法。 ---- 冒泡排序的算法思想 通过两两比较相邻的数，如果发现这两个数不满足次序要求使，则将这两个数进行交换，从而实现"冒泡"。...---- 冒泡排序的实现过程 从序列的最后一个数开始，不断地将小的数往上冒，通过n-1(假设有n个数)次循坏之后，这组序列就成了一个有序的序列。...---- 代码实现 public static void bubbleSort (int[] a) { for(int i =0;i循坏的次数为...j] = a[j-1]+a[j]-(a[j-1]=a[j]); //将两个数进行交换，也可以通过中间值temp进行交换 } } } 运行下面代码...public static void bubbleSort(int[] a ) { for(int i=0;i循坏的次数为n-1次
如果循环迭代次数只有几次，那么可以完全展开循环，以便消除循坏带来的负担。...使用位运算替代四则运算 在许多古老的微处理器上， 位运算比加减运算略快， 通常位运算比乘除法运算要快很多。在现代架构中， 位运算的运算速度通常与加法运算相同，但仍然快于乘法运算。...K&R C设计者认为复合赋值符可以让程序员把代码写得更清楚些。另外，编译器可以产生更为紧凑的代码。...在第一种形式种，由于编译器无从知道f函数是否具有副作用，所以它必须两次计算数组a的下标表达式的值。而在第二种形式中，下标表达式只需计算一次，所以第二种形式效率更高。...并且，从书写的角度看，第一种形式的下标表达式需要书写两次，而第二种形式只需书写一次。 尽量使循环体内的工作量达到最小化 循环中，随着循环次数的增加，会加大对系统资源的消耗。
要用这些自动化单元测试去测多少代码呢？还要说吗？全部！全部都要测 这一种方法，就是TDD，来规避这个问题。 作者是TDD的践行者 如果连所有代码是否都可以正常运行都不知道，还算什么专业人士？...聪明的开发者们宁可在出了问题花大量的精力去一步步调试，也不愿花一点点的时间去写单元测试，执行TDD。...曾经在读云风博客时，发现一段有共鸣的话 反感围绕着调试的开发方式，也是不断的在测试，试错，纠正的循环中奔波，好的程序员应该努力的在编写的过程中，在头脑中排错，在预感到坏味道时，就赶紧重写，而坏味道就是代码陷入了复杂度太高的境地...对付复杂度最好的武器是简化代码 在遇到bug时，应该仔细浏览代码，设想各种出错的可能。而不是将错误代码运行起来，查看运行中的状态变化 这段话中不赞成的解决问题方式，其实是很多开发人员普遍具备的。...这是时间管理时提到的，李笑来也讲，注意力是你最宝贵的财富 时间在本质上不属于你，你只能试着与它做朋友，让它为你所用。你的注意力才是你所拥有最重要、最宝贵的资源。你可以自己作主，要把它放在“成长”上。
学习重构必看的一本神书《重构：改善代码既有设计》从两个角度给出了重构的定义： 重构（名词）：对软件内部结构的一种调整，目的是在不改变软件可观察行为的前提下，提高其可理解性，降低其修改成本。...让代码更容易理解 ：通过添加注释、命名规范、逻辑优化等手段可以让我们的代码更容易被理解； 避免代码腐化 ：通过重构干掉坏味道代码； 加深对代码的理解 ：重构代码的过程会加深你对某部分代码的理解； 发现潜在...开发一个新功能之后&之前 在开发一个新功能之后，我们应该回过头看看是不是有可以改进的地方。在添加一个新功能之前，我们可以思考一下自己是否可以重构代码以让新功能的开发更容易。...我们在阅读理解代码的时候，如果发现一些坏味道的话，我们就可以对其进行重构。...另外，多提一句：持续集成也要依赖单元测试，当持续集成服务自动构建新代码之后，会自动运行单元测试来发现代码错误。 怎样才能算单元测试呢？ 网上的定义很多，很抽象，很容易把人给看迷糊了。
推荐以后写并发的时候在复习一遍 代码规范 注释 不要给不好的名字加注释，一个好的名字比好的注释更重要 不要“拐杖注释”，好代码 > 坏代码 + 好注释 在文件/类级别使用全局注释来解释所有部分如何工作...，而非明显的细节 不要在代码中加入代码的著作信息，git可以干的事情不要交给代码 源代码中的html注释是一种厌物, 增加阅读难度 注释一定要描述离它最近的代码 注释一定要与代码对应 公共api需要添加注释...，其它代码谨慎使用注释 典型的烂注释 不恰当的信息 废弃的注释 冗余注释 糟糕的注释 注释掉的代码 唯一真正好的注释是你想办法不去写的注释 不要有循规式注释，比如setter/getter注释...经常性地通读标准库的整个API，保持对他们的熟悉程度 简单设计 运行所有测试 不可重复 表达了程序员的意图 尽可能减少类和方法的数量 以上规则按重要程度排列 无论是设计系统或者单独模块，别忘了使用大概可工作的最简单方案...整洁的代码只提供一种而非多种做一件事的途径，他只有尽量少的依赖。
因为在很多单元测试框架运行测试的过程中，测试不过时会用红色展示测试结果，而通过时则采用绿色进行展示，这已经成了单元测试框架约定俗成的规则。...然而，这种想问题的方式会让人忽略新增代码可能带来的 坏味道（Code Smell），坏味道会让代码逐渐腐坏，这是一个工程问题，也就是会有长期影响的问题。...对很多人来说，TDD 是一种难以接受的做法，抛开理念上的差异，更重要的原因是，写测试无从下手。很多时候写不出测试，主要是面对的需求太大了。...单元测试框架写测试的方式更多的是面向具体的实现，这种做法的层次是很低的，BDD 希望把这个思考的层次拉高。拉到什么程度呢？...如果登录方式有所调整，用户输完用户名密码自动登录，不需要点击，那这个用例是不是需要改呢？下面我换了一种方式描述，你再感受一下。
“重构”，因为刚刚只是让代码跑起来了，设计上还有可改之处，新增代码往往存在很多“坏味道”，而重构则是消除坏味道的手段，一旦有了测试，就可以大胆的进行重构，因为任何错误都可以很容易的被捕捉到。...如果把“先写代码，后补测试”转换成：先写测试，写代码是为了让测试通过，写出的代码天然具备可测性，是不是就变得简单了呢？...在实际开发工作中，经常能见到长达100行及以上的函数/方法，这种代码绝大部分开发者会说不具备可测性。如果写代码时时刻想着可测性，是为了让测试通过，开发者再写这么长行数的代码都难。...一种测试常见的坏味道是没有断言！这种测试就从来没失败过，一看代码竟然是print，这种测试最多也就能证明你曾经debug过这段代码。...结合到日常开发工作中，可以在以下几个节点进行： 添加功能时一并重构 修复BUG时一并重构 代码评审时一并重构 是不是有些情况，也不适合重构？
一种做法是获取Answer的属性，然后再进行验证。那么，为了测试的验证而暴露这些属性，是否适合？ 要完成对答案正确性的验证，直接暴露答案的属性是不妥当的，至少目前没有获取答案属性的需求。...毕竟，这种对答案正确性的校验，也可以说是业务逻辑的一种。 说明：在开始编写“检查输入是否合法”任务时，你会发现，这里所谓多余的验证，就会派上用场。...一种是传统的在测试代码中通过编写try... catch结合fail()方法进行验证。这种方法带来的问题是验证逻辑太繁琐。 第二种方法是利用@Test的expected方法，通过指定异常类型值来验证。...随机数带来了不确定性，它可能偶然地让测试通过了。也许，运行测试100次，前面的99次都通过了，最后一次失败，仍然视为失败。 生成随机数自然是调用Java的JDK。...在单元测试环节中，倘若我们要测试的单元需要调用别的API，则在这个测试中，我们可以假定这个API是正确的。我们对Java JDK的正确性自然信心十足。那么，为何我们还要考虑测试的随机失败？
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
云直播
腾讯会议
