an agent does not care about the structure, unless you specifically ask it to. But even in this case you have to review the changes.
【启发】「AI 天然不在意结构，除非你明确要求」——这个发现定义了人类工程师在 AI 时代最不可替代的职责：做代码结构的「守门人」。这与 Every 文章里「每个人都是管理者」的洞见形成呼应：人类的工作从「执行代码」转变为「审查代码质量并为 AI 设定标准」。对工程团队文化的启发：代码 Review 的重要性不是在下降，而是在上升——因为现在需要 Review 的代码量是以前的 10 倍。
TypeTest(x, obj.type, FALSE) ; x.type := ORB.boolType
The explicit x.type assignment here is redundant, because TypeTest will have already done it (in this case because the third argument is false).
IF sym = ORS.ident THEN ORS.CopyId(modid); ORS.Get(sym); Texts.WriteString(W, modid); Texts.Append(Oberon.Log, W.buf) ELSE ORS.Mark("identifier expected") END ;
This "IF...ELSE Mark, END" region could be reduced by replacing the three lines corresponding to those control flow keywords with a single call to Check:
Check(ORS.ident, "identifier expected");
In very large code bases, it is likely impossible to make a change to a fundamental API and get it code reviewed by every affected team before merge conflicts force the process to start over again.
how was your code review experience with this merge request? Please tell us how we can continue to iterate and improve: Leave a 👍 or a 👎 on this comment to describe your experience.
Danger runs after your CI, automating your team's conventions surrounding code review.
A review from the Technical Writing team before you merge is recommended. Reviews can happen after you merge.
Each commit should meet the following criteria: Have a well-written commit message. Has all tests passing when used on its own (e.g. when using git checkout SHA). Can be reverted on its own without also requiring the revert of commit that came before it. Is small enough that it can be reviewed in isolation in under 30 minutes or so.
Don’t make claims unless you can cite documentation, formalized guidelines, and coding examples to back those claims up. People need to know why they are being asked to make a change, and another developer’s personal preference isn’t a good enough argument.
You are context switching between new features and old commits that still need polishing.
body script, body style {
This doesn't work well with scripts (and style elements) injected by the Hypothesis bookmarklet or the Wayback Machine's toolbar. On that note, it's pretty poor hygiene on their part to (a) inject this stuff in the body to begin with, and (b) not include at the very least a class attribute clearly defining the origin/role of the injected content. As I described elsewhere:
set the class on the injected element to an abbreviated address like
<style class="example.org/sidebar/2.4/injected-content/">. And then drop a page there explaining the purpose and requirements (read: assumptions) of your injected element. This is virtually guaranteed not to conflict with any other class use (e.g. CSS rules in applied style sheets), and it makes it easier for other add-ons (or the page author or end user) to avoid conflicts with you.
* Monospace fonts always render at 80% of normal body text for some * reason that I don't understand but is still annoying all the same.
Dealing with it this way is a mistake. The only reasonable thing to do is to tell the user to adjust their browser's default font settings or deal with it. (This seems to only affect Firefox's default UA stylesheet/preferences, not Chrome.)
Check out how the most recent iteration of the w2g streamline "client" https://graph.5apps.com/LP/streamline approaches styling.
Yes, autoexpect is a good tool, but it is used just to automatically create TCL-expect scripts, by watching for user. So it’s can be equal to writing expect-scripts by hand.
he goes on to talk about third party problems and how you're never guaranteed something is written correctly or that even if it is you don't know if it's the most optimal solution
here is my set of best practices.I review libraries before adding them to my project. This involves skimming the code or reading it in its entirety if short, skimming the list of its dependencies, and making some quality judgements on liveliness, reliability, and maintainability in case I need to fix things myself. Note that length isn't a factor on its own, but may figure into some of these other estimates. I have on occasion pasted short modules directly into my code because I didn't think their recursive dependencies were justified.I then pin the library version and all of its dependencies with npm-shrinkwrap.Periodically, or when I need specific changes, I use npm-check to review updates. Here, I actually do look at all the changes since my pinned version, through a combination of change and commit logs. I make the call on whether the fixes and improvements outweigh the risk of updating; usually the changes are trivial and the answer is yes, so I update, shrinkwrap, skim the diff, done.I prefer not to pull in dependencies at deploy time, since I don't need the headache of github or npm being down when I need to deploy, and production machines may not have external internet access, let alone toolchains for compiling binary modules. Npm-pack followed by npm-install of the tarball is your friend here, and gets you pretty close to 100% reproducible deploys and rollbacks.This list intentionally has lots of judgement calls and few absolute rules. I don't follow all of them for all of my projects, but it is what I would consider a reasonable process for things that matter.
reviewing code takes energy!
.then((res) => {
Please, just type result.