Skip to main content
Commonmark migration
Source Link

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

 

klass or clazz for class: Class clazz = ThisClass.class

 

kount for count in SQL: count(*) AS kount

 

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

 

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

 

klass or clazz for class: Class clazz = ThisClass.class

 

kount for count in SQL: count(*) AS kount

 

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

 

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

added 22 characters in body
Source Link
kevin cline
  • 33.7k
  • 3
  • 72
  • 142

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(benchmark.generatedClass(),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(ClassUtils.loadClass(benchmark.generatedClass()),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.

Source Link
kevin cline
  • 33.7k
  • 3
  • 72
  • 142

I often see code that include intentional misspellings of common words that for better or worse have become reserved words:

klass or clazz for class: Class clazz = ThisClass.class

kount for count in SQL: count(*) AS kount

Personally I find this decreases readability. In my own practice I haven't found too many cases where a better name couldn't have been used — itemClass or recordTotal.

However, it's so common that I can't help but wonder if I'm the only one? Anyone have any advice or even better, quoted recommendations from well-respected programmers on this practice?

For local variables and formal arguments, it just doesn't matter.

Any name is fine as long as it is not intentionally misleading or annoyingly distracting. In your example:

public static Method findBenchmarkMethod(BenchmarkRecord benchmark) {
    Class<?> clazz = ClassUtils.loadClass(benchmark.generatedClass());
    return findBenchmarkMethod(clazz, benchmark.generatedMethod());
}

it doesn't matter whether the single local variable is "clazz" or "klass" or "cls" or simply "c". I would probably just inline the expression:

return findBenchmarkMethod(benchmark.generatedClass(),
                           benchmark.generatedMethod());

The length of a variable name should be related to the variable's scope. For local variables in short methods (and they should all be short), very short names are fine.