TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The Source of Readability

44 pointsby benhoytover 1 year ago

3 comments

slaymaker1907over 1 year ago
I&#x27;m going to push back somewhat on global variables. I think they can actually be very helpful when you are working in the debugger, particularly with memory dumps. Instead of looking across a bunch of different threads, you can inspect globals directly.<p>In terms of not wasting vertical space, I think you&#x27;ll run into issues since it starts to conflict with readability from familiarity. People aren&#x27;t used to having a bunch of statements on a single line so they may not notice it. There&#x27;s a similar phenomenon with reading research papers where it is very time consuming initially because you may be unfamiliar with the structure, but after a while, you can read them very quickly since you know what to skip over and what to pay close attention to.
评论 #37798360 未加载
gavinhowardover 1 year ago
I break two of these all the time: minimize vertical space and define variables close to their use.<p>I&#x27;m one of those people that prefer braces on their own mine, even left braces.<p>But it works for me. Empty space actually helps me read my code more easily.<p>Likewise, in C, I define all variables at the top of a scope. This is dangerous in C because of the possibility of uninitialized data, but Clang catches everything. And I prefer it because Clang has a warning to enforce that style so that I can&#x27;t mix styles. Also, using those variables becomes like using type inference in other languages; the first use looks like initialization without the type annotation.<p>Not that the author is wrong, but don&#x27;t feel bad if you depart from this for your own personal stuff. And follow whatever style policy is required by your employer.
blackoilover 1 year ago
To novice, most of these are guidelines, don&#x27;t treat them as rules. If something feels wrong to you, you are free not to follow them. Also almost always follow the conventions of your team&#x2F;project. Nothing is worse than multiple coding styles in a project, unless whole team finds it better and decides to follow it.<p>Clear naming will give you most ROI. When you have confusion follow the simplest path, it is always easier to refactor simple code later.