TypeTest(x, obj.type, FALSE) ; x.type := ORB.boolType

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 ;

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 {

* 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.

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) => {