有时会有一些已更改的文件以及一些新的,已删除和/或重命名的文件.在做git diff或者git-log我想省略它们时,我可以更好地发现修改.

实际上,列出新文件和已删除文件的名称是最好的.对于"旧"重命名为"新"我想选择性地区分"旧"和"新".

制作所有字段final通常都是一个好主意,但有时我发现自己在构造函数中做了所有事情.最近我最终得到了一个类,它实际上构建了构造函数中的所有内容,包括读取属性文件和访问数据库.

一方面,这就是该类的用途,它封装了读取的数据,我喜欢创建完全初始化的对象.构造函数并不复杂,因为它委托了大部分工作,所以它看起来很好.

另一方面,感觉有点奇怪.此外,在大约17:58的这次演讲中,有充分的理由不在构造函数中做很多工作.我想我可以通过传递适当的假人作为构造函数参数来消除这个问题.

问题仍然存在:构建器中的大量工作(甚至是所有工作)都不好吗？

我通过cygwin在Windows上使用git并很快决定使用filemode=false(因为否则我在最初的git clone之后有很多变化).我根本不对跟踪权限感兴趣,我唯一想到的是一些文件是可执行的.有时,我发现x某些文件上的标志会丢失,我强烈认为这是因为git.

我很满意一个允许chmod a+x ...在需要时执行的解决方案.

我的Eclipse javadoc视图有一个黑色的背景,使它看起来很糟糕,部分不可读(例如链接是黑色的深蓝色).更糟糕的是,javadoc弹出窗口也有黑色背景.我找不到相应的设置.

Sumit Singh的回答向我展示了如何更改javadoc视图的背景.但是,我仍然看不到如何改变前景.更糟糕的是,javadoc弹出窗口背景颜色没有改变.

我不认为它是由插件引起的,因为它也是在全新安装时发生的.这发生在Ubuntu 10.4上.在Windows中,颜色也不能改变,但也很好.

类Enum中的方法hashCode()是final,定义为super.hashCode(),这意味着它根据实例的地址返回一个数字,该数字是来自程序员POV的随机数.

将其定义为例如ordinal() ^ getClass().getName().hashCode()跨不同JVM的确定性.它甚至可以更好地工作,因为最低有效位会"尽可能地改变",例如,对于包含多达16个元素的枚举和大小为16的HashMap,肯定没有碰撞(当然,使用EnumMap更好,但有时不可能,例如没有ConcurrentEnumMap).根据目前的定义,你没有这样的保证,对吗？

答案摘要

使用Object.hashCode()比较如上所述的更好的hashCode,如下所示:

• PROS
  • 简单
• CONTRAS
  • 速度
  • 更多冲突(对于任何大小的HashMap)
  • 非确定性,传播到其他对象,使其无法使用
    • 确定性模拟
    • ETag计算
    • 根据例如HashSet迭代顺序搜寻错误

我个人更喜欢更好的hashCode,但恕我直言,没有理由权重,可能除了速度.

UPDATE

我对速度感到好奇并写了一个令人惊讶的结果的基准.对于每个类的单个字段的价格,您可以使用确定性哈希码,其速度快近四倍.将哈希码存储在每个字段中会更快,尽管可以忽略不计.

标准哈希码不快得多的原因是它不能成为对象的地址,因为对象被GC移动了.

更新2

一般来说,表演会有一些奇怪的事情发生hashCode.当我理解它们时,仍然存在未解决的问题,为什么System.identityHashCode(从对象标题读取)比访问普通对象字段慢.

我们知道使用double货币是容易出错的,不推荐使用.但是,我还没有看到一个现实的例子,BigDecimal虽然double失败了,但不能通过一些舍入来简单地修复.

注意琐碎的问题

double total = 0.0;
for (int i = 0; i < 10; i++) total += 0.1;
for (int i = 0; i < 10; i++) total -= 0.1;
assertTrue(total == 0.0);

不计算,因为它们通过舍入(在这个例子中从0到16的小数位的任何东西)都可以解决.

涉及总结大值计算可能需要一些中间圆棒,但由于流通总货币之中USD 1e12,爪哇double(即标准IEEE双精度其15个十进制数字)仍然是足够美分事件.

涉及分工的计算通常是不精确的,即使是BigDecimal.我可以构造一个不能用doubles 执行的计算,但可以BigDecimal使用100的标度执行,但它不是你在现实中可以遇到的东西.

我没有声称这样一个现实的例子不存在,只是我还没有看到它.

我也肯定同意,使用double更容易出错.

例

我正在寻找的是如下方法(根据Roland Illig的回答)

/** 
  * Given an input which has three decimal …

用于回溯的配置文件可以在类路径中找到,因此是特定于Eclipse项目的,这不是我想要的.我正在使用多个Java实用程序,它们都驻留在一个项目中(这个共享类路径),我需要为其中一些使用特定的配置.

我尝试过变量替换和Joram配置器,但没有什么对我有用.这很可能是我的错,我有一天会解决它,但是现在我需要一个简单的解决方案.

通常,Java会根据给定调用端遇到的实现数量来优化虚拟调用.当你看一下,这可以很容易地在我的基准测试结果中看到,这是一个返回存储的简单方法.这是微不足道的myCodeint

static abstract class Base {
    abstract int myCode();
}

与几个完全相同的实现

static class A extends Base {
    @Override int myCode() {
        return n;
    }
    @Override public int hashCode() {
        return n;
    }
    private final int n = nextInt();
}

随着实现数量的增加,方法调用的时序从两个实现的0.4 ns增加到1.2 ns,再增长到11.6 ns,然后缓慢增长.当JVM看到多个实现时,preload=true即时序略有不同(因为instanceof需要进行测试).

到目前为止,一切都很清楚,但hashCode行为却相当不同.特别是,在三种情况下,它慢了8-10倍.知道为什么吗？

UPDATE

我很好奇,如果hashCode可以通过手动调度来帮助穷人,那可能会很多.

几个分支完美地完成了这项工作:

if (o instanceof A) {
    result += ((A) o).hashCode();
} else if (o instanceof B) {
    result += ((B) o).hashCode(); …

我正在使用

git diff mycommit

用于比较我的工作树mycommit,但它似乎忽略了当前索引中不存在的文件.您可以按如下方式重现它:

git init
echo A > A.txt; git add .; git commit -m A; git branch A
echo B > B.txt; git add .; git commit -m B; git branch B
git reset --hard A
echo BB > B.txt
git diff B

输出(从git版本1.7.3.3开始)为空.使用--diff-filter=ACDMRTUXB显示错误的"已删除文件",因为该文件同时B.txt存在于工作树和提交中B.恕我直言,该文件应显示为已修改.令人惊讶的是,它在将文件添加到索引后起作用,尽管它不是比较的索引.没有它我怎么能得到正确的差异？

该结果我的基准测试表明,性能最差的时候该分支下有15%(或85%)%的概率,而不是50%.

任何解释？

代码太长但相关部分在这里:

private int diff(char c) {
    return TABLE[(145538857 * c) >>> 27] - c;
}

@Benchmark int timeBranching(int reps) {
    int result = 0;
    while (reps-->0) {
        for (final char c : queries) {
            if (diff(c) == 0) {
                ++result;
            }
        }
    }
    return result;
}

它计算给定字符串中BREAKING_WHITESPACE字符的数量.结果显示当分支概率达到约0.20时突然下降(性能增加).

关于跌落的更多细节.改变种子表明发生了更多奇怪的事情.请注意,表示最小值和最大值的黑线非常短,除非靠近悬崖.