If you use a dash, make sure to use the “em” dash, which is three times longer than a hyphen. There are a number of ways to present this same information, but in this case the dashes break up the information while keeping it as part of the same thought. json, located in the fabric - samples folder inside first - network - which will serve as the baseline for our config update. This leaves us with a trimmed down JSON object - config. For example, when referencing an attribute as part of an Access Control List.ĭashes can be incredibly useful but they’re not necessarily as technically appropriate as using separate declarative sentences.
Rocketchat markdown code#
It might also make sense to put back tics around words that do make sense in plain English that are part of the code if you’re referencing them in a code context. Same with a code function like hf.Revoker. So for example, when talking about the fabric-samples directory, surround fabric-samples with back tics. This is useful to draw attention to words that either don’t make sense in plain English or when referencing parts of the code (especially if you’ve put code snippets in your doc). When to surround something in back tics nnn? Avoid using them simply to emphasize a single word, as in something like “Blockchain networks must use propery security protocols”. “A blockchain network contains a ledger, at least one chaincode, and peers”, especially if you’re going to be talking about those things in that paragraph. The best use of them is either as a summary or as a way of drawing attention to concepts you want to talk about.
Rocketchat markdown free#
This restriction is no longer necessary, so you are free to make lines as long as you want. If you look at the raw versions of the documentation, you will see that many topics conform to a line length of roughly 70 characters. While not all files use this standard, new files should adhere to it. For example, identity_use_case_tutorial.md. But excessive usage of any particular word has a tendency to have a numbing effect on the reader.īy using underscores between words. Of course sometimes it might not be possible to avoid this –– a doc about the state database being used is likely to be replete with uses of the word “database” or “ledger”. Not using it more than twice in a single paragraph is better. If you can avoid using a word twice in one sentence, please do so. Try to avoid using the same words too often. For example, “Software Development Kit (SDK)” on first usage. The first usage of an acronym should be spelled out, unless it’s an acronym that’s in such wide usage this is unneeded.
Avoid them unless you have a reason to use it (such as in a code snippet that includes it). It’s perfectly fine to use the “you” or “we”. Do not call it a “RAFT ordering service”. The Fabric CA client binary can, however, be referred to as the fabric-ca-client. The commands themselves are “curl” commands.ĭo not call it “fabric-CA”, “fabricCA”, or FabricCA. The same applies for any file format (for example, YAML). If you’re talking about several chaincodes, use “chaincodes”.Ĭolloquially, smart contracts are considered equivalent to chaincode, though at a technical level, it is more correct to say that a “smart contract” is the business logic inside of a chaincode, which encompasses the larger packaging and implementation. Don’t use “HLF” or “Hyperledger” by itself. The first usage should be “Hyperledger Fabric” and afterwards only “Fabric”. For an example, check out Use private data in Fabric. Tutorials should have a list of steps at the top.Ī list of steps (with links to the corresponding sections) at the beginning of a tutorial helps users find particular steps they’re interested in. Either be more explicit (for example, describing what “whitelisting” actually does) or find alternate words such as “allowlist” or “blocklist”. Unless the use of these words is absolutely necessary (for example, when quoting a section of code that uses them), do not use these words. Avoid the use of the words “whitelist”, “blacklist”, “master”, or “slave”.
0 kommentar(er)
