Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Articulate Coding

casestatement.tumblr.com

Post reply on HN
Print view View original

21–29 of 29 posts

Re: Articulate Coding

#21

Post by rcfox »

methodin wrote: post #18
apaprocki wrote: post #16

Earlier quoted context omitted.

The two go hand-in-hand. Writing articulate easy-to-read code does not mean it precludes thinking about the things you mention. You could be the best (according to your criteria) coder in the world, but if your code is unreadable, it will quite literally waste others' time. This might not seem like a big deal with a smaller project, but scale to something the size of the Linux kernel or larger and it begins to become…

I've rarely seen such poor code visually that it made it hard to follow - except in the rare case where someone commits line breaks incorrectly. Camel-case, underscores, indentation etc.. do not vary so widely as to prevent me from understanding code. What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting. Have you actually experienced a coder that writes good…

> What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting.

What's worse is multiple nested levels of #ifdef. Not only is it hard to tell how the code flows, but you can't even be sure it's all being compiled!

I work with code like this so frequently that I actually got around to learning elisp so that I could write a function in Emacs to highlight the nested levels of #ifdef. I have a black background, so each nested level increases the brightness.

(I should really get around to pulling that code off of my computer at work and putting it up for everyone to use...)

Re: Articulate Coding

#22

Post by dustingetz »

OP is unintentionally superficial, but he's grasping at a greater understanding and he knows. I think this is what he is looking for:

Why is this idea true?

Do I really believe it?

Could I convince someone else that it is true?

Why didn't the author use a different argument?

Do I have a better argument or method of explaining the idea?

Why didn't the author explain it the way that I understand it?

Is my way wrong?

Do I really get the idea?

Am I missing some subtlety?

Did this author miss a subtlety?

If I can't understand the point, perhaps I can understand a similar but simpler idea?

Which simpler idea?

Is it really necessary to understand this idea?

Can I accept this point without understanding the details of why it is true?

Will my understanding of the whole story suffer from not understanding why the point is true?

-- How To Read Mathematics, authors Shai Simonson and Fernando Gouvea [1]

[1]http://web.stonehill.edu/compsci/History_Math/math-read.htm#

Re: Articulate Coding

#23

Post by dustingetz »

apaprocki wrote: post #16
methodin wrote: post #15

These 12 points seem to be the most insignificant things you can think about your code. Indentation? Camel case? Come on... mastering WRITING code will not make you a good coder. It will make your code consistent, I'll concede, but there's nothing stopping your from writing consistently bad code that looks good. Wouldn't it be more fruitful to think things like: 1) Why did I write this code as one function? 2) Should…

The two go hand-in-hand. Writing articulate easy-to-read code does not mean it precludes thinking about the things you mention. You could be the best (according to your criteria) coder in the world, but if your code is unreadable, it will quite literally waste others' time. This might not seem like a big deal with a smaller project, but scale to something the size of the Linux kernel or larger and it begins to become…

as long as the code isn't deliberately formatted poorly, i don't care, not even a bit. besides our codebase we have a large set of dependencies, and we read and maintain dependencies all the time. whether their coding style is consistent with mine is irrelevant, I slog through it and stfu and get my job done.

Re: Articulate Coding

#24

Post by shabble »

rcfox wrote: post #21
methodin wrote: post #18

Earlier quoted context omitted.

I've rarely seen such poor code visually that it made it hard to follow - except in the rare case where someone commits line breaks incorrectly. Camel-case, underscores, indentation etc.. do not vary so widely as to prevent me from understanding code. What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting. Have you actually experienced a coder that writes good…

> What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting. What's worse is multiple nested levels of #ifdef. Not only is it hard to tell how the code flows, but you can't even be sure it's all being compiled! I work with code like this so frequently that I actually got around to learning elisp so that I could write a function in Emacs to highlight the nested le…

That code sounds pretty interesting, especially if it's adaptable to arbitrary open/close sequences

    if (.*?) {
vs

    #ifdef .* ... #else ... #endif
I'd be interested in seeing it, even if it's a pastebin/gist dump that needs some cleanup.

Re: Articulate Coding

#25

Post by gruseom »

ColinWright wrote: post #10
kenkeenan wrote: post #7

Earlier quoted context omitted.

Agreed, but some of these questions-- the ones about indent style in particular-- don't seem to me to be the kind of things a developer needs to be thinking about while they're working on getting code written. The endless bickering and bikeshedding that arguments over coding conventions always result in are one thing, but having these arguments with yourself, every time you write a line of code, is crazy!

But the point was exactly not to be making these decisions consciously every time you write code. The point - in agreement with you - was that these decisions are not necessarily important. The argument is that these decisions are made, whether you are aware of them or not, and in this case Beck was undertaking to understand them in nit-picking detail so they can be made visible and better understood, rather than rem…

In my 35 years of software work, far, far too often I see people concentrating on the pointless

The pointless has one great advantage: it is easier to work with. Hard problems are The Unknown, we fear the unknown, and when this fear arises one way to resolve it is by replacing the hard problem with something easier. This is absurd, like the drunk looking for his car keys under the street lamp on the wrong side of the street "because the light's better here", but that doesn't stop us, it just means we do it unconsciously. Now we have a simpler problem that we can concentrate on and (best of all) argue about.

You see this in obvious places like curly brace wars, but there are more interesting examples, such as why editors and version control systems get so much attention. They're important, but not that important. But they're easy to understand and have an opinion about. Better still, they're common across many projects so arguing about them is a way for programmers to socialize.

Perhaps the same pattern is behind our industry's tendency to embrace savior paradigms (Structured Programming, OO, Agile, FP).

Re: Articulate Coding

#27

Post by rcfox »

shabble wrote: post #24
rcfox wrote: post #21

Earlier quoted context omitted.

> What does prevent me from understanding code is 5-10 nested if blocks and insane logic checks without commenting. What's worse is multiple nested levels of #ifdef. Not only is it hard to tell how the code flows, but you can't even be sure it's all being compiled! I work with code like this so frequently that I actually got around to learning elisp so that I could write a function in Emacs to highlight the nested le…

That code sounds pretty interesting, especially if it's adaptable to arbitrary open/close sequences if (.*?) { vs #ifdef .* ... #else ... #endif I'd be interested in seeing it, even if it's a pastebin/gist dump that needs some cleanup.

Unfortunately, it's only for #if .* ... #el.* ... #endif. I didn't want to write that much of a parser, so I just push the line number onto a stack if I see a line like /^\s*#if/.

I guess Emacs is using some kind of parser to do syntax highlighting, right? I wonder if it's possible to tap into that...

Re: Articulate Coding

#28

Post by pmiller2 »

apaprocki wrote: post #17
arctangent wrote: post #13

I understand the point of the exercise and I can see that an individual coder might gain some benefit from this. However, in a professional environment you would expect that the lead developer(s) had already given this stuff a lot of serious thought and enshrined it in a coding standards document for every member of the team to follow.

A good idea is to check for certain style issues which you want to enforce and are easy to catch at checkin time. You can enforce things like no real tabs, line width, no trailing spaces, etc and make the person checking in the code get rid of it. Usually once it winds up in VCS[1], it is harder to go back and clean it up. People make mistakes all the time, and tools are scriptable. [1] Or do it at merge time if your…

I'd argue that if it's so easy to check you can do so with a commit hook, you should also automate fixing it. If you're using C, C++, C#, or Java, you can do this with astyle pretty easily, for instance.

Re: Articulate Coding

#29

Post by shabble »

rcfox wrote: post #27
shabble wrote: post #24

Earlier quoted context omitted.

That code sounds pretty interesting, especially if it's adaptable to arbitrary open/close sequences if (.*?) { vs #ifdef .* ... #else ... #endif I'd be interested in seeing it, even if it's a pastebin/gist dump that needs some cleanup.

Unfortunately, it's only for #if .* ... #el.* ... #endif. I didn't want to write that much of a parser, so I just push the line number onto a stack if I see a line like /^\s*#if/. I guess Emacs is using some kind of parser to do syntax highlighting, right? I wonder if it's possible to tap into that...

Yeah, I'm pretty sure it does, although I've never poked deeply enough / understood elisp well enough to know exactly how it does it.

Swapping out those regexen you have wouldn't be too much of a challenge, I don't think, at least for a first shot at it.

I'm more interested in the general structure of managing the counter, applying the various faces to lines, etc.

My email is in profile if you want someone to attempt to clean it up a bit (insofar as I'm capable of doing so) :)

Post reply on HN