5 ms·
Deriving meaning from the context requires understanding the context. That's fine for the original author or the refactoring dev, but the troubleshooter swoopi
by randallsquared 10y ago
Deriving meaning from the context requires understanding the context. That's fine for the original author or the refactoring dev, but the troubleshooter swooping in to fix that problem that's obvious in the UI needs to be able to understand the variable names with as little context as possible. "Well, if you'd just spent a few hours to truly grok the intent of the code, ..." is not an acceptable answer when it's possible to make the solution transparent as easily as making more descriptive names.
- kryptiskt 10y agoLong names that are constantly repeated makes the code very tough to read, there are many Java codebases that show that effect.
- nine_k 10y agoIn Java, you just have to repeat types twice very often: DescriptivelyNamedFoo = new DescriptivelyNamedFoo(); In a language with even limited type inference, e.g. C#, this repetition is gone.
- natch 10y agoVery well put. I wish everybody could get this concept. With this kind of attitude, you are going to write code that is easier to read, is easier to update and debug, and has fewer bugs in the first place.
- barrkel 10y agoCode with long identifiers is harder to read, not easier to read. It's harder to see the flow of data and the flow of control, because there is invariably a soup of common prefixes throughout, performing the contextualization.
- natch 10y agoThe identifiers don't all have to be long. Just long enough to be clear.
- skybrian 10y agoDescriptive names are great when a symbol is used in many scattered places. Context is okay when the definition is right in front of you. When a function is short enough, context for a parameter should mean reading the function's documentation written immediately above it. Or if the scope of a local variable is three lines, its initializer often explains what it is, and it's right there.
- barrkel 10y agoIf you're in the middle of the spreadsheet reader, it should be self-evident that 'row' means a row in the spreadsheet; if you're in the middle of the database insertion logic, it should be self-evident that 'row' means a row in the database. I simply don't accept your priors.
- randallsquared 10y agoI use 'row' as a variable name quite a lot, especially in loopy situations where it's obvious. The more problematic times are when you have things like a source and a destination row dealing with, say, cows, and you call one of them 'row' and the other one 'cow\_row', and in different places pick which kind of row is which at apparent random. Or the situation with the file names, as someone else mentioned at more length.
- deleted 10y ago[deleted]