[程序员英语口语][Clean code]Chapter1-11Exceptions you should be aware of

本文链接：https://blog.youkuaiyun.com/lingfy1234/article/details/122850765

Clean code

chapter1 naming

1.11 Exceptions you should be aware of

Now of course, no good rule comes without exception, So all the rules I walked you through over the last lectures, of course, apply, but there are a couple of exceptions you might wanna be aware of.

And you see one right here.This is a python code snippet using the datetime library, which is part of the python standard library.
在这里插入图片描述

So it’s a build in module shipping together with python which you can use if you need datetime specific functionality.

Now I’m calling datetime.now() here to get the current timestamp of today, right at this minute where this code executes.

and this gives us a date object which then can format to a string with certain formatting rules by using the strftime method here.

And as you can clearly tell, these names actually violate what I taught you over the last minutes.

Now is a method as you can tell by the brackets, we are executing it. It’s a method, not a property.

Hence it sounds like a property. it’s not describing a command and it’s also not returning a boolean where something like is_now would be acceptable.

Instead it’s just now and not something like getNow or getCurrentTimestamp. No, that’s not how it’s named. It’s name now.

And since it’s a built in library, you of course can’t change it. This was defined by other people you can’t override it.

The strftime method here also has a lot of strange name. I’m not sure if it sounds like a command because it’s pretty hard to tell what this should be.

I can tell you that strftime should stand for string from time because it returns a string from a date time object, but of course this is really not intuitive, and therefore, in my opinion, not really a great name.

In addition, even string from time is not really a command. but again, more like a property name.

Now again, this is build into python or into a python code library, so you won’t be able to change it.

It does not mean that you have to use the same naming in your code though.

You should try to follow the rules outlined over the last lectures, unless you have a good reason for not doing so.

For example, for everyone in your team agrees that you wanna to follow a different naming convention.

And of course naming convention can also differ across different languages, though in python,you typically should not follow the name you see here on the datetime library, because I would argue it’s not super readable.

now it’s okay. but strftime is totally unintuitive, you need to hover over that to understand what is does. and even that might not be enough. so you might need to dive into the official doc to understand what it does.

And if you just explore the available methods here with all the completion, you see,this method don’t tell you anything. so it’s not easy to quickly see what you wanna call to achieve a certain result.

so that just proves my point, that naming matter, and that good names matter, and I would argue that there are not great names.

And of course as I said, there is nothing we can change about it, but we also don’t have to copy it into our code.

Now speaking of our code, this code snippets has more to ofter than these build in library method names here.

For example, I defined my own class. And I named it DateUtil, Now DateUtil is not too far away from this manager pattern, which I just said a couple minutes ago that you shouldn’t use,
在这里插入图片描述

you should’t use name like DataBaseManager, remember? DateUtilis quite similar, but actually here is really an exception.

Naming classes like this DateUtil or DateUtility to be even more expressive can make senses, especially if they mostly contain static method like this one does.

A static method of course is a method which can be call without instantiating the class first, like we’re doning it down there.

then the class simply is there to group related functionality together and adding something like utils, utility, or even manager in the class name can make sense to signal that this will not be instantiated.

but that it’s just a grouping of well, utility or helper methods like we have here. so these are some exceptions and things to be aware of.

Another exception can be seen in this code snippet, which now is written in typescript, and therefore javascript.

Here I have a database class which have a private property client. which is actually set when the connect method is called.

however since that property is private, it can’t be accessed from outside the class. For that we instead have this connected client getter.

And getters and setters are a special concept which exist in multiple programming languages to provide you as a developer with greater control over how data in a class can be read or set.

For example, a getter allow us to control access to certain properties in the class, in this case we control whether client is initialized before we return it.

And here you will notice that even though connected client is written like a method, it has brackets and a function body.

It actually has a name like a property. It’s not get connected client, but instead just connected client, because actually this getter would be accessed like a property.

that’s just a language feature Javascript offers. and many other programming languages have similar concept

So for getter and setters,It’s okay to use property naming rules, even though it’s technically written as a method.

But since we access it as a property,we should also name it as such. So that’s another exception to be aware of.

however even with all these exceptions I just showed you, it should become clear and obvious that these rules which I outlined over the last lectures are super important and apply in the vast majority of cases.

Recomment：