java代码审计入门篇(java代码审计入门篇电子书)

Java编程importjava.io.*;publicclassMain{privatestaticintlevel;publicstaticvoidgetSubDir(Filefile){if(file.isDirectory()){for(inti=0;i

Java编程

import java.io.*;

public class Main {

private static int level;

public static void getSubDir(File file) {

if (file.isDirectory()) {

for (int i = 0; i < level; i++) {

System.out.print(“*”);

}

System.out.println(file.getName() + ” <—— is directory”);

for (int i = 0; i < file.listFiles().length; i++) {

level++;

getSubDir(file.listFiles()[i]);

level–;

}

} else if (file.isFile()) {

for (int i = 0; i < level; i++) {

System.out.print(“*”);

}

System.out.println(file.getName());

return;

} else {

throw new RuntimeException();

public static void main(String[] args) {

File file = new File(“c:\\windows”);

getSubDir(file);

利用递归便利文件夹,并将文件夹名称和文件名称输出,名称前面的星星代表嵌套级数,还行啊?

java代码审计入门篇

如何写出优雅Java编程

一、不要使用魔法数字,尽量定义枚举、常量、宏:

我常常见到表示各种状态的数字,0,1,2….,我真的不知道这表示什么含义,如果

你在不在文档中说明的话,这个东东过几天连你自己都不知道个一二三了。

二、命名要具有描述力,尽量使用全名而不是自创的缩写,除非地球人都这么用这个缩写:

我常常看到一些自创的缩写,这个缩写或许只有你自己知道,类名,方法名,参数名

尤其要有好的描述里,局部变量尚可容忍。我宁可容忍超过40个字符的命令,也不愿意

看到只有一两个字母的命名,当然迭代用的i,j除外。当然命名不要太长,太长说明你的类和

方法要做的事情太多,请你拆分出更多细粒度功能单一的类和方法。

三、同一类东东命名方式尽可能统一,比如类名使用大写字母开头的单词,变量使用

下划线分割开来的小写字母单词,常量使用下滑线分割的开来的大写字母单词。不要

交替使用。

四、函数、类功能尽可能单一,不要试图写一个万能/超级函数或者类。

一个类和方法要有单一的职责,这样的类和方法只做一件事,并且容易把他做好。

1、不要试图写一个强大无比的方法。

我常常看到一些试图写的多么“精妙”无比多么“强大”的函数,事实上不是什么精妙,而是

代码的臭味道。精妙强大无比万能的方法往往你耗费大量精力去设计算法,试图覆盖现在的各

种可能,而无法面对将来新的需求,随着新的需求,你的这个精妙的方法需要的修改并且改起来

极其痛苦。在一次次的痛苦与精妙的演化中,你的方法越来越复杂,并且每一次修改你都会面

临影响以前功能的风险。这个方法使用者需要小心的处理你的精妙之处,如果没有精妙传递好参

数,那么这个方法再也不精妙了,而是直接废掉了。

KISS(keep it simple and stupid)原理就是这个道理,你要使你的代码尽可能简单,让人

看到有一目了然的清爽,而不是因为设计了一个精妙无比的万能方法而沾沾自喜。这里的简单不是

简洁的代名字。有时候简洁是那种传说的“精妙”的代码。

2、不要写做多件事情的方法和类,你做一件事情,你就写一个对应的方法,不要试图通过参数来判定各种情况,然后做事情,并且做的事情和你方法描述的不一致。当你发现你的方法名字想不出来好的名字了,或者要加or和and了,那么请你拆分出更多单一的方法。

不要举一些linux完成多种功能系统调用,这是被迫的,因为系统调用的数量是有限制的,它只有有限的空间来描述系统调用号和系统调用的映射表,不要在应用程序开发中效仿而误以为优雅强大。我最恶心根据参数,然后一大堆的if..else 和switch..case判断。

五、不要修改已有的类和方法而是扩展它。

这是程序设计的一个重要原则,开闭原则,在面向对象的语言中尤为重要。在面向过程中主要表现在,不要在一个函数要应对和这个函数相似的一个需求了,就在这个加个if,来修改这个方法,试图重用和避免重复。而是要把公用的部分抽出来成一个小的功能函数,然后增加一个应对新的类似这个需求的处理方法。在面向对象中,例如使用策略模式、访问者模式、Extend Object模式。

六、不要重复你自己(DRY):

程序最怕的是copy,paste,到处是重复的代码。copy,paste经常被误以为快速完成需要用的功能的高效方式而被到处使用。你每重复一次,你就得负责保持他们的一致性,你就得在一处增加新的功能时,你就的把这个的功能加到其他地方。还在我刚会写代码的时候去了一个小公司,他们的代码到处是copy,paste的痕迹,当要在现有的功能增加审计功能是,他们开始下命令了,每个人加几行代码来做审计,真不知道那么多人写的审计版本,分散到那么多处,这个审计功能是否可信有用。

避免DRY的方法就是抽象,分离变化。不管是面向对象还是面向过程,分离变化并抽象之是最主要的设计原则。设计模式中的模板方法,我们常用的回调都是我们常用的方法。

我发现越是提供更多回调处理的语言和框架,就越具有灵活性和易用性。ruby语言之所以有如此的威力,主要是因为它提供了更多的回调处理。它可以在动态的给一个类增加方法,这样可以在超类中定义增加方法的方法,然后再子类调用,子类就具有无比的能力。它的block提供了强大的回调机制,我只要不知道如何处理了我就yield出来,method missing机制更是神秘无比,你可以写出像find_by_name_and_age,2.days.ago这样像自然语言一样易读的代码。

七、不要跨越边界,在适合的地方写代码。

在分层的架构中,不要跨越层的边界。例如web开发的三层架构:

数据访问层(DAO)、业务层(Service)、表现层。

不要在业务层裸写SQL来做事情,不要在业务层掺和进来表现层的东东,不要在表现层/控制器中写业务的东东。既然已经分层了,那么就要好好的遵守它,如果到处跨越边界的话,那么和不分层没有什么区别,使得每一层都不伦不类。例如你应该在业务层进行事务管理,而你的控制器到处是业务代码,那将无法控制。如果你的业务层到处是SQL,我不知道你的DAO存在的意义了。

八、分层的web架构:

DAO层最好按照模型来划分dao类,如果业务很简单,也可以将相关的模型合并为一个DAO。

Service层,不要按照DAO和Service一一对应的方式划分,而是要按照业务的类别和实际情况来划分。事实上Service层通常是用来处理涉及到多个模型的业务,而涉及到一个模型的业务,常常被放在模型中,这是一种自然而更面向对象的设计方法。只有数据的模型被称为贫血型模型,这种模型被认为是对面向对象的一种背离,而在模型中放置专有的业务方法,不仅有利于公用,而且模型更具有描述力。

九、关于MVC:

MVC是一种松耦合的设计方案,最容易误用的就是控制器(c)。控制器只负责调用业务方法,准备好数据供View去展现。而不要把业务和如何展示的东东放在里面。我常常看到有人在控制器中拼html片段和写一些业务相关的代码。

十、顺便说一下异常的使用。

如果你是使用语言支持异常机制,那么尽可能的使用异常机制和定义好与自己业务相关的异常,而不是通过返回值表示正确和错误。如果你使用的语言支持异常机制,请不要写类linux下c似的代码形式,每写一个函数,我就写一个判断返回值调用是否成功,严重分离了我对核心业务的关注。异常提供了优雅的处理错误的方法。

转载请注明出处:http://www.qiaomu818.com/sjbg/2540.html

(0)
上一篇 2021年11月29日 下午1:53
下一篇 2021年11月29日 下午1:55

相关推荐

发表评论

您的电子邮箱地址不会被公开。