[Documentation]: Minor updates in Private APIs

docs/contributors/code/coding-guidelines.md

@@ -244,7 +244,7 @@ Each `@wordpress` package wanting to privately access or expose experimental API
 do so by opting-in to `@wordpress/private-apis`:
 
 ```js
-// In packages/block-editorwordpress/private-apis.js:
+// In packages/block-editor/private-apis.js:
 import { __dangerousOptInToUnstableAPIsOnlyForCoreModules } from '@wordpress/private-apis';
 export const { lock, unlock } =
 	__dangerousOptInToUnstableAPIsOnlyForCoreModules(
@@ -366,6 +366,7 @@ const {
 Remember to always register the private actions and selectors on the **registered** store.
 
 Sometimes that's easy:
+
 ```js
 export const store = createReduxStore( STORE_NAME, storeConfig() );
 // `register` uses the same `store` object created from `createReduxStore`.

packages/private-apis/README.md

@@ -1,28 +1,28 @@
-# Experiments
+# Private APIs
 
-`@wordpress/private-apis`  enables sharing private `__experimental` APIs across `@wordpress` packages without
+`@wordpress/private-apis` enables sharing private `__experimental` APIs across `@wordpress` packages without
 [publicly exposing them to WordPress extenders](https://make.wordpress.org/core/2022/08/10/proposal-stop-merging-experimental-apis-from-gutenberg-to-wordpress-core/#respond).
 
 ## Getting started
 
 Every `@wordpress` package wanting to privately access or expose experimental APIs must opt-in to `@wordpress/private-apis`:
 
 ```js
-// In packages/block-editorwordpress/private-apis.js:
+// In packages/block-editor/private-apis.js:
 import { __dangerousOptInToUnstableAPIsOnlyForCoreModules } from '@wordpress/private-apis';
 export const { lock, unlock } =
 	__dangerousOptInToUnstableAPIsOnlyForCoreModules(
 		'I know using unstable features means my plugin or theme will inevitably break on the next WordPress release.',
 		'@wordpress/block-editor' // Name of the package calling __dangerousOptInToUnstableAPIsOnlyForCoreModules,
-								  // (not the name of the package whose APIs you want to access)
+		// (not the name of the package whose APIs you want to access)
 	);
 ```
 
 Each package may only opt in once. The function name communicates that plugins are not supposed to use it.
 
 The function will throw an error if the following conditions are not met:
 
-1. The first argument must exactly match the required consent string: `'I know using unstable features means my plugin or theme will inevitably break on the next WordPress release.'`. 
+1. The first argument must exactly match the required consent string: `'I know using unstable features means my plugin or theme will inevitably break on the next WordPress release.'`.
 2. The second argument must be a known `@wordpress` package that hasn't yet opted into `@wordpress/private-apis`
 
 Once the opt-in is complete, the obtained `lock()` and `unlock()` utilities enable hiding `__experimental` APIs from the naked eye:
@@ -60,17 +60,15 @@ import { lock } from './private-apis';
 
 export const experiments = {};
 /* Attach private data to the exported object */
-lock(experiments, {
-	__experimentalFunction: function() {},
-});
+lock( experiments, {
+	__experimentalFunction: function () {},
+} );
 
 // In packages/package2/index.js:
 import { experiments } from '@wordpress/package1';
 import { unlock } from './private-apis';
 
-const {
-	__experimentalFunction
-} = unlock( experiments );
+const { __experimentalFunction } = unlock( experiments );
 ```
 
 ## Shipping experimental APIs