或者一个开发人员重用了这个构造器来校验一个潜在的用户所希望的用户名和密码，那么他就被迫作出了一个不需要的远程调用，因为这些方法(isRequestedUsernameValid(), isRequestedPasswordValid())不需要账户状态。

    习惯2：方法名清晰的表达方法的意图

    第二个习惯是，通过它们的方法名，所有的方法必须清晰的传递它们的意图。例如，isRequestedUsernameValid()让开发人员知道这个方法确定请求的用户名是否是合法的。与之相对照的是，isGoodUser()可能有好几种用途：它能决定一个用户的账户是否是活跃的，决定是否请求的用户名或密码是正确的，或者决定用户是否是一个好人。既然这个方法名的描述性不强，那么它对于其他开发人员来说很难确定它的意图是什么。简短地说，一个方法名使用长的和描述性的比使用短的和毫无意义的好。

    长的、描述性的方法名帮助开发团队迅速的理解他们的软件的意图和功能。此外，应用这种技术到测试方法的名称，使得测试表达了软件现有的需求。例如，软件要求检验请求的用户名和密码是不同的。使用方法名称：testRequestedPasswordIsNotValidBecauseItMustBeDifferentThanTheUsername() 就能传递测试的这个意图，因此为表达了软件需求的意图。

    这个测试方法可以很简单的被命名为testRequestedPasswordIsNotValid()，或者更差的 testBadPassword()，这两个名称都使得它很难确定测试的意图。不清楚地或者说含糊不清的名称将导致效率的损失。效率的损失导致需要增加额外的时间来理解测试、创建不需要的方法或属性、重复的或者冲突的测试、或者销毁了对象已经测试过的已经存在的功能。

    最后，描述性的方法名减少了对于常规文档或者Javadoc注释的需要。