{"id":229969,"date":"2022-11-08T18:41:00","date_gmt":"2022-11-08T15:41:00","guid":{"rendered":"https:\/\/wordpress.mediadoma.com\/?p=229969"},"modified":"2022-11-09T19:30:43","modified_gmt":"2022-11-09T16:30:43","slug":"standard-di-codifica-di-base-tramite-psr-1","status":"publish","type":"post","link":"https:\/\/wordpress.mediadoma.com\/it\/standard-di-codifica-di-base-tramite-psr-1\/","title":{"rendered":"Standard di codifica di base tramite PSR-1"},"content":{"rendered":"\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/it\/utilizzo-dei-psr-rispetto-agli-standard-di-codifica-di-wordpress\/\" title=\"Ieri\" >Ieri<\/a> ho parlato brevemente di una logica per l&#8217;utilizzo dei <a href=\"http:\/\/www.php-fig.org\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">PSR<\/a> rispetto agli <a href=\"https:\/\/codex.wordpress.org\/WordPress_Coding_Standards\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">standard di codifica di WordPress<\/a> e del quando e del perch\u00e9 di entrambi. Ma questo non significa che non sia privo di punti di confusione soprattutto se stai appena iniziando con loro, giusto?<\/p>\n<p>Con questo, intendo: supponiamo che tu abbia lavorato con gli standard di codifica di WordPress per anni (perch\u00e9 posso relazionarmi) e ora c&#8217;\u00e8 questo insieme completamente nuovo di regole e linee guida da seguire. Ma non \u00e8 come una semplice questione di modificare alcuni spazi bianchi e rinominare i file.<\/p>\n<p>Ci sono altri punti da seguire, e ognuno \u00e8 delineato in un numero, letteralmente (PSR-1, PSR-2 e cos\u00ec via), di come dovrebbe funzionare qualcosa.<\/p>\n<p>Quindi, quando si tratta solo degli standard di codifica di base come delineato in PSR-1, quali sono alcune aree problematiche che potremmo incontrare come sviluppatori di WordPress?<\/p>\n<h2>Standard di codifica di base (ed effetti collaterali)<\/h2>\n<p>Non ho intenzione di esaminare ciascuno dei documenti e ricostruire ci\u00f2 che possiamo gi\u00e0 imparare semplicemente <a href=\"http:\/\/www.php-fig.org\/psr\/psr-1\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">leggendoli<\/a>, ma penso che ci sia qualcosa da dire per prendere qualcosa che molti di noi fanno o sperimentano e vedere come questo potrebbe cambiare all&#8217;interno il contesto di WordPress.<\/p>\n<p>Prendi gli <strong>effetti collaterali<\/strong> dallo standard di codifica di base (o <a href=\"http:\/\/www.php-fig.org\/psr\/psr-1\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">PSR-1<\/a> ), ad esempio:<\/p>\n<blockquote>\n<p>Un file DOVREBBE dichiarare nuovi simboli (classi, funzioni, costanti, ecc.) e non causare altri effetti collaterali, oppure DOVREBBE eseguire la logica con effetti collaterali, ma NON DOVREBBE fare entrambi.<\/p>\n<p>La frase &quot;effetti collaterali&quot; indica l&#8217;esecuzione di una logica non direttamente correlata alla dichiarazione di classi, funzioni, costanti, ecc., semplicemente dall&#8217;inclusione del file.<\/p>\n<\/blockquote>\n<p>Personalmente, trovo la seconda frase la chiave per comprendere ed evitare il pi\u00f9 possibile gli effetti collaterali nel nostro codice. Cio\u00e8, tutto ci\u00f2 che fanno le nostre classi dovrebbe essere autonomo o essere coeso con qualcosa che potrebbe essere stato iniettato in qualche modo.<\/p>\n<p>Indipendentemente da ci\u00f2, trovare codice che introduce un effetto collaterale e ripulirlo non dovrebbe essere troppo difficile. In effetti, user\u00f2 me stesso come esempio.<\/p>\n<p>Guarda questo particolare <a href=\"https:\/\/gist.github.com\/tommcfarlin\/f9de10bd98d0ba3dd22c914b01fad140#file-00-toggle-admin-notices-php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">pezzo di codice<\/a> :<\/p>\n<pre><code>&lt;?php\n\nnamespace TAN;\nuse TANAdmin;\n\ninclude_once( 'admin\/class-toggle-admin-notices-node.php' );\ninclude_once( 'admin\/interfaces\/interface-asset.php' );\ninclude_once( 'admin\/class-javascript-assets.php' );\n\nadd_action( 'plugins_loaded', __NAMESPACE__. 'tan_start' );\n\/**\n * Initializes the JavaScript loader and the Administration Bar Node for\n * rendering the option to toggle admin notices.\n *\/\nfunction tan_start() {\n  \/\/ Code removed for brevity.\n}\n<\/code><\/pre>\n<p>Questo codice proviene direttamente da <a href=\"https:\/\/tommcfarlin.com\/wordpress-admin-notices\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">Toggle Admin Notice<\/a>. Certo, \u00e8 semplice e il <a href=\"https:\/\/github.com\/tommcfarlin\/toggle-admin-notices\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">repository<\/a> mostra una nota su come cambiarlo. Dimostra comunque il punto, giusto?<\/p>\n<p>Qual \u00e8 la soluzione? Questo si presenta sotto forma di Autoloading (che \u00e8 anche trattato in <a href=\"http:\/\/www.php-fig.org\/psr\/psr-4\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">PSR-4<\/a> ). E se dovessi rifattorizzarlo, in modo che seguisse correttamente PSR-1? Quindi un modo per refactoring potrebbe <a href=\"https:\/\/gist.github.com\/tommcfarlin\/f9de10bd98d0ba3dd22c914b01fad140#file-01-toggle-admin-notices-autoloading-php\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">essere simile a questo<\/a> :<\/p>\n<pre><code>&lt;?php\n\nnamespace TAN;\nuse TANAdmin;\n\ninclude_once 'inc\/autoload.php';\n\nadd_action( 'plugins_loaded', __NAMESPACE__. 'tan_start' );\n\/**\n * Initializes the JavaScript loader and the Administration Bar Node for\n * rendering the option to toggle admin notices.\n *\/\nfunction tan_start() {\n  \/\/ Code removed for brevity.\n}\n<\/code><\/pre>\n<p>\u00c8 un ottimo esempio? Probabilmente no. Ma c&#8217;\u00e8 di pi\u00f9 oltre a includere solo i file. Includere quei file significa che questo singolo file introduce una variet\u00e0 di effetti collaterali.<\/p>\n<p>Ci\u00f2 significa che solo questo file \u00e8 responsabile di fare molto di pi\u00f9 di quelle quattro righe di codice. Pensalo come incorporare tutto ci\u00f2 che implementano altri file. Diventa pi\u00f9 complesso a quel punto.<\/p>\n<p>Quindi prendi quell&#8217;idea e spostala in un sistema molto pi\u00f9 ampio e puoi vedere come e perch\u00e9 questo sarebbe problematico.<\/p>\n<p>Naturalmente, ci sono anche modi alternativi. E questo \u00e8 solo un esempio. Anche autoironico. Il punto non \u00e8 tanto mostrare un modo definitivo per farlo, ma iniziare a seminare pensieri su come progettiamo, pianifichiamo, costruiamo e incorporiamo le classi.<\/p>\n<h3>E per quanto riguarda le visualizzazioni?<\/h3>\n<p>Quando si tratta di scrivere plug-in, sono parziale nel trattare ci\u00f2 che gli utenti vedranno come <strong>visualizzazioni.\u00a0<\/strong>Ma sembra esserci un problema qui: \u00e8 considerata una cattiva pratica includere file poich\u00e9 introduce effetti collaterali.<\/p>\n<p>Quindi non vogliamo produrre logica nelle nostre classi, ma vogliamo anche separare la presentazione dalla logica aziendale.<\/p>\n<p><a href=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-166223-61e7906a0bf19.png\" data-rel=\"lightbox\"><img decoding=\"async\" class=\"SDStudio-light-box-enable SDStudio-editor-tools-md-imp\" src=\"https:\/\/wordpress.mediadoma.com\/wp-content\/uploads\/2022\/01\/post-166223-61e7906a0bf19.png\" alt=\"Standard di codifica di base tramite PSR-1\" ><\/a><\/p>\n<p>Cosa dobbiamo fare?<\/p>\n<blockquote>\n<p>Il colpo di scena&#8230; \u00e8 che useremo la programmazione orientata agli oggetti per farlo. Progetteremo una classe che genera HTML utilizzando il modello PHP.<\/p>\n<\/blockquote>\n<p>Questo \u00e8 stato trattato in modo approfondito <a href=\"https:\/\/carlalexander.ca\/designing-class-generate-wordpress-html-content\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">da qualcun altro<\/a> e consiglio vivamente di leggere quel particolare post per prendere l&#8217;idea degli effetti collaterali, evitarli e incorporare pratiche solide il pi\u00f9 possibile.<\/p>\n<h2>\u2026E asset e file correlati?<\/h2>\n<p>Lo so: l&#8217;idea di allontanarsi dagli effetti collaterali (per non parlare di identificarli) pu\u00f2 essere strana all&#8217;inizio, specialmente se si pensa a certe cose che abbiamo fatto per cos\u00ec tanto tempo.<\/p>\n<p>E potrebbe sollevare domande come: includere file JavaScript o file CSS \u00e8 sbagliato? Questo \u00e8 probabilmente un argomento per un altro post. Ricorda, tuttavia, che ci sono funzioni API di base direttamente correlate a ci\u00f2 e potrebbero far parte di una classe strettamente responsabile di farlo.<\/p>\n<p>Se lo scopo di una classe \u00e8 quello di fare esattamente questo e solo quello e utilizza le funzioni API per farlo, direi che probabilmente va bene.<\/p>\n<p>Ma per ora divago su questo (e forse \u00e8 un argomento per i commenti o, ancora, un altro post).<\/p>\n<p>Invece, mantieni le tue lezioni snelle e propositive. Dovrebbero fare come afferma <a href=\"http:\/\/www.php-fig.org\/psr\/psr-1\/\" target=\"_blank\" rel=\"noopener nofollow\" class=\"external external_icon\">PSR-1<\/a> ed evitare di fare cose come &quot;[dichiarare] nuove classi, funzioni, costanti, ecc.&quot; e &quot;[esecuzione] logica con effetti collaterali&quot;.<\/p>\n<p><div id=\"PostUnique_PostSource\" style=\"padding-top: 50px\">Fonte di registrazione:  <a target=\"_blank\" rel=\"noopener nofollow\" href=\"\/\/tommcfarlin.com\" class=\"external external_icon\">tommcfarlin.com<\/a><\/div><\/p>\n","protected":false},"excerpt":{"rendered":"<p>Mantieni le tue lezioni mirate. Evita cose come &#8220;[dichiarare] nuove classi, funzioni, costanti, ecc.&#8221; e &#8220;[esecuzione] logica con effetti collaterali&#8221;.<\/p>\n","protected":false},"author":1,"featured_media":166224,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_wp_rev_ctl_limit":""},"categories":[720],"tags":[1168],"class_list":["post-229969","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sviluppatore","tag-affiai-it"],"_links":{"self":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/229969","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/comments?post=229969"}],"version-history":[{"count":0,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/posts\/229969\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media\/166224"}],"wp:attachment":[{"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/media?parent=229969"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/categories?post=229969"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wordpress.mediadoma.com\/it\/wp-json\/wp\/v2\/tags?post=229969"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}