findbugs

概述 今天介绍的插件主要是围绕编码规范的。有追求的程序员，往往都有代码洁癖，要尽量减少代码的「坏味道」。 代码静态检查是有很多种类，例如圈复杂度、重复率等。业界提供了很多静态检查的插件来识别这些不合规的代码，帮助提高项目的质量。比较知名的一个产品是 SonarQube，它提供了一个「门禁」平台，集成了很多静态检查检查。下次有机会介绍一下该平台的搭建。 本文主要介绍 IDEA 中对于 Java 语言静态检查的好插件： Alibaba Java Coding Guidelines 阿里基于他们 Java 规范提供的插件 CheckStyle-IDEA 检查代码的格式是否符合规范 FindBugs-IDEA 检查代码是否有常见的一些 Bug Alibaba Java Coding Guidelines 阿里巴巴 Java 编码指南插件支持。 首先说说阿里的 p3c 项目，它的 Github 主页地址是： https://github.com/alibaba/p3c 阿里之前开源过一份 Java 开发手册。手册从编程规约、异常日志、单元测试、MySQL 数据库、工程结构、设计规约等角度，介绍了阿里的 Java 开发规范，这个对于 Java 新手帮助挺大的，能够学到不少东西。有一些坑可能老司机也会翻车。 开发人员 Coding 时，可能就忘记规范了，写出来的代码还是会有『坏味道』。这时候

IDEA一些不错的插件分享 目录 IDEA一些不错的插件分享 插件集合 CamelCase Translation LiveEdit MarkDown Navigator Jrebel CheckStyle-IDEA Alibaba Java Coding Guidelines Ideavim Maven Helper FindBugs-IDEA GsonFormat Key promoter X .ignore JVM Debuger Memory View CMD Support Batch Scripts Support BashSupport Docker integration JMH plugin ANSI Highlighter Ideolog RestfulToolkit CodeGlance Lombok plugin activate-power-mode Background Image Plus Iedis Mongo Plugin VisualVM Launcher GenerateAllSetter MyBatisCodeHelperPro Easy Code IDEA Mind Map SequenceDiagram Material Theme UI String Manipulation JUnit Generator V2.0 设置方法 插件集合

首先准备一个hadoop源码包，我选择的hadoop版本是：hadoop-2.7.7-src.tar.gz，在hadoop-2.7.7的源码包的根目录下有一个文档叫做BUILDING.txt，这其中说明了编译hadoop所需要的一些编译环境相关的东西。不同的hadoop版本的要求都不一样，对应的版本参照BUILDING.txt 安装对应软件（必须联网） 安装openssl-devel yum -y install svn yum -y install autoconf automake libtool cmake zlib-devel lzo-devel yum -y install ncurses-devel yum -y install openssl-devel yum -y install zlib1g-dev libssl-dev 安装gcc 检测gcc是否已经安装:gcc -v 如果最后一行出现gcc版本信息日志，表示已经安装成功过了 命令安装： yum install -y gcc 安装gcc-c++ 命令安装：yum -y install gcc-c++ 安装JDK 安装包：jdk-7u80-linux-x64.tar.gz 解压安装：tar -zxvf /root/jdk-7u80-linux-x64.tar.gz -C /root/apps/ 配置环境变量：

原文链接 原文作者：Dani Buiza 译者：Toien Liu 校对：深海 编者的话：注解是java的一个主要特性且每个java开发者都应该知道如何使用它。 我们已经在Java Code Geeks提供了丰富的教程, 如 Creating Your Own Java Annotations , Java Annotations Tutorial with Custom Annotation 和 Java Annotations: Explored & Explained . 我们也有些文章是关于注解在不同类库中的应用，包括 Make your Spring Security @Secured annotations more DRY 和 Java Annotations & A Real World Spring Example . 现在，是时候汇总这些和注解相关的信息到一篇文章了，祝大家阅读愉快。 目录 什么是注解 介绍 消费器 注解语法和注解元素 在什么地方使用 使用案例 内建注解 Java 8 与注解 自定义注解 提取注解 注解集成 使用注解的知名类库 小结 下载 资料 在这篇文章中我们将阐述什么是Java注解，它们如何工作，怎么使用它们。 我们将揭开Java注解的面纱，包括内建注解或称元注解，还将讨论Java8中与之相关的的新特性。 最后，我们将实现自定义的注解

作者：琦彦 blog.csdn.net/fly910905/article/details/77868300 1.设置maven 1.在File->settings->搜索maven 2.Mavan home directory--设置maven安装包的bin文件夹所在的位置 3.User settings file--设置setting文件所在的位置 4.Local repository--设置本地仓库 2.IDEA 设置代码行宽度 1.在File->settings->Editor->Code Style 2.有人会问，如果输入的代码超出宽度界线时，如何让IDE自动将代码换行？``有两种方式！ 3.第一种，在上述的“Right margin (columns)”的下方，有“Wrap when typing reaches right margin”选项，选中它，是什么效果呢？ 4.随着输入的字符的增加，当代码宽度到达界线时，IDEA会自动将代码换行。 5.第一种方式是在输入代码时触发，还有第二种方式，在File->settings->Code Style->Java中，选中“Wrapping and Braces”选项卡， 6.在“Keep when reformatting”中有一个“Ensure rigth margin is not exceeded”，选中它

背景 前阵子阿里巴巴发布了 <<阿里巴巴Java开发手册(终极版)>> 。 不久，又一气呵成发布了Eclipse/Intellij Idea下的代码检测插件 PC3 ，可谓是国内代码优秀的检测插件。此插件检测的标准是根据<<阿里巴巴Java开发手册(终极版)>>上面制定的规定进行检测的。 如何使用 代码检测插件放到了github上： https://github.com/alibaba/p3c 打开这个网站，在上面可以找到Eclipse/Intellij Idea对应的插件，上面有安装的方法，和其他的插件安装方法一样，所以这里不再重复，其使用也相当简单。 如在Idea下，随便右击一个项目，选择：编码规约扫描，再会对该项目进行扫描并在下面显示该项目不符合规约的所有列表。 当然，也可以在Tools菜单中进行选择扫描，还有可以切换英文，默认是中文的。另外，默认是打开实时检测的，个人认为没有必要实时检测，这样会增加工具的笨重，开发完提交代码时进行一次扫描还是比较合适的，所以建议关闭实时检测功能。 体验了一下，感觉这个插件检测的要点还是挺重要的，符合国人开发规范及思维，推荐配合findbugs同时使用。 推荐去我的博客阅读更多： 1. Java JVM、集合、多线程、新特性系列教程 2. Spring MVC、Spring Boot、Spring Cloud 系列教程 3. Maven

今日小组成员任务完成情况： 小组12-9工作量 成员 今日工作 备注 郭义 未完成白盒测试文档（延期） 未完成任务(12-12日任务已完成） 杜杰 完成了代码复审方法 完成任务 侯俊 完成了 findbugs测试文档 完成任务 李嘉蕊、姜黎黎 完成缺陷报告模板 完成任务 唐伟 编写今日博客 完成任务（后期添加未完成组员的部分） 小组完成文档总览 白盒测试用例如下图 代码评审会议纪要 1、主持人（杜杰）对项目及此次会议做整体介绍。 2、小组其余成员（姜黎黎、唐伟、李嘉蕊、侯俊、郭义）根据代码评审标准，以及对代码的阅读，填写评审表。 3、主持人结合代码讲解发现的问题，每讲完一个问题，针对其展开讨论，每个问题控制在10分钟以内。 4、 主持人组织全体与会人员召开会议并记录会议过程。 评审结果报告 一、概要部分 全组人员开的代码复审会议中，首先，对项目的源码从头到尾进行复审，看代码是否符合需求和规格说明，然后检查代码是否有周全的考虑，以及代码的可读性和可维护性，经过小组成员的审核和讨论，确认该项目的代码全部符合以上要求。 二、设计规范部分 对代码进行了初步的复审后，然后小组成员开始分块对项目代码进行设计规范部分的复审。经过大家的复审，确认项目代码遵从了已知的设计模式或项目中常用的模式，没有硬编码或字符串/数字等存在，没有依赖于某一平台，不会影响将来的移植（如Win32到Win64）