Closing tag en newline
Best practice is het weglaten van de PHP closing tag en een newline aan het einde van je PHP bestand.
Ik heb daarom na mijn laatste code geen closing tag en een harde enter gegeven zodat er een nieuwe regel ontstaat.
Echter, ik blijf de melding krijgen dat er "No newline at end of file" is.
Wat doe ik verkeerd? Ik gebruik trouwens meestal WordPad.. Verder nooit gedoe mee gehad, ook al is dat misschien niet een geschikte code editor?
Guido
En waar zie je die melding "No newline at end of file" dan? Want Wordpad is nooit gebouwd om in te programmeren.
Melding staat in de bevestigingsmails die ik krijg nadat ik de bestanden geupload heb naar de WordPress repository.
Guido
Guido
Ik stap vanaf nu maar over op Notepad++
Terug te komen op mijn vraag, een enter na mijn laatste PHP code zorgt voor de gewenste newline?
Guido
- Ariën - op 06/09/2017 22:41:00:
Inderdaad! Lees je eens in in Git!
Zet er voor de zekerheid wel even bij dat die opmerking ironisch is bedoeld, anders gaan mensen die hier toevallig voorbijkomen misschien denken dat het juist de bedoeling is dat je Git moet gaan gebruiken...
Ik vind het even teveel werk om alle redenen op te noemen waarom Git een waardeloos product is, maar het simpele feit dat Git het mogelijk maakt de historie van je bestanden aan te passen, maakt het in mijn ogen al volkomen ongeschikt als versiebeheersysteem. Subversion is op vrijwel alle fronten de minder slechte keuze.
Guido vd Leest op 06/09/2017 21:34:03:
"No newline at end of file"
Die git-melding staat er alleen om te laten zien dat er geen newline aan het einde van het bestand staat. Die melding staat er niet omdat er een newline aan het einde zou moeten staan. Het is slechts een neutrale observatie, geen gekleurd waardeoordeel:
https://stackoverflow.com/questions/5813311/no-newline-at-end-of-file
https://stackoverflow.com/questions/9921927/php-is-there-a-reason-to-put-a-newline-at-the-end-of-file
Willem vp op 07/09/2017 00:21:46:
Zet er voor de zekerheid wel even bij dat die opmerking ironisch is bedoeld, anders gaan mensen die hier toevallig voorbijkomen misschien denken dat het juist de bedoeling is dat je Git moet gaan gebruiken...
Ik vind het even teveel werk om alle redenen op te noemen waarom Git een waardeloos product is, maar het simpele feit dat Git het mogelijk maakt de historie van je bestanden aan te passen, maakt het in mijn ogen al volkomen ongeschikt als versiebeheersysteem. Subversion is op vrijwel alle fronten de minder slechte keuze.
- Ariën - op 06/09/2017 22:41:00:
Inderdaad! Lees je eens in in Git!
Zet er voor de zekerheid wel even bij dat die opmerking ironisch is bedoeld, anders gaan mensen die hier toevallig voorbijkomen misschien denken dat het juist de bedoeling is dat je Git moet gaan gebruiken...
Ik vind het even teveel werk om alle redenen op te noemen waarom Git een waardeloos product is, maar het simpele feit dat Git het mogelijk maakt de historie van je bestanden aan te passen, maakt het in mijn ogen al volkomen ongeschikt als versiebeheersysteem. Subversion is op vrijwel alle fronten de minder slechte keuze.
Ik weet dat het totaal niet hoort in dit topic. Maar wat een bullshit.
http://oliverguenther.de/2016/01/rewriting-subversion-history/
Is ook gewoon prima te doen in SVN.
En ik stel voor dat je de volgende link ook leest: https://stackoverflow.com/questions/871/why-is-git-better-than-subversion/875#875
Geen appels met peren vergelijken dus als je gaat bashen.
Beiden systemen hebben hun voor en nadelen.
Remco van Bers op 07/09/2017 10:01:38:
Ik weet dat het totaal niet hoort in dit topic. Maar wat een bullshit.
http://oliverguenther.de/2016/01/rewriting-subversion-history/
Is ook gewoon prima te doen in SVN.
http://oliverguenther.de/2016/01/rewriting-subversion-history/
Is ook gewoon prima te doen in SVN.
Je hebt het artikel zeker niet gelezen? ;-) Er wordt namelijk in beschreven dat het niet mogelijk is, en het beschrijft vervolgens hoe je door de *volledige* repository opnieuw te creëren een specifieke versie kunt verwijderen (niet eens wijzigen, alhoewel dat op die manier in principe ook zou kunnen). Dat is toch wel andere koek dan simpelweg een rebase-commando uitvoeren. En ja, de Git-documentatie zegt dat je dat niet zomaar moet doen, maar dat Git het uberhaupt faciliteert vind ik ernstig.
Quote:
En ik stel voor dat je de volgende link ook leest: https://stackoverflow.com/questions/871/why-is-git-better-than-subversion/875#875
Dat topic is 9 jaar oud. Ik schat dat ongeveer driekwart van wat daar gezegd wordt inmiddels achterhaald of op zijn minst verouderd is. Zo roept iemand in een van de commentaren dat SVN in elke directory een .svn-directory aanmaakt. Dat is sinds 2011 al niet meer het geval...
Quote:
Geen appels met peren vergelijken dus als je gaat bashen.
Beiden systemen hebben hun voor en nadelen.
Beiden systemen hebben hun voor en nadelen.
Ik vind Git geen peer, maar een misvormde appel. Op grond daarvan mag ik vergelijken. ;-)
Het enige voordeel wat ik tot nu toe (en ik heb me 15 jaar full-time met versiebeheer beziggehouden, met 9 verschillende versiebeheersystemen in omgevingen met 10 tot 1200 ontwikkelaars) van Git heb gezien, is dat je wijzigingen kunt committen (en dus een update-trail kunt bijhouden) als je geen netwerk tot je beschikking hebt. Vind ik een wat zwakke basis om je complete versiebeheer op te baseren. Ik zou dan eerder gaan voor git-svn, waarbij je op netwerkloze momenten Git gebruikt en daarna je wijzigingen synchroniseert met de SVN-repository. Maar we dwalen af.
<poging om het gesprek weer on-topic te krijgen>
Wordpad voegt inderdaad bij tekstbestanden niet automatisch een newline toe aan het eind van de laatste regel; je moet dus altijd zorgen dat je document eindigt met een lege regel.
Versiebeheertools (daarbij maakt het eigenlijk niet uit of dat Git is, of SVN, of nog iets anders) slaan nieuwe versies van een element in principe op als wijzigingen ten opzichte van de vorige versie. Daarvoor wordt de Unix-utility 'diff' gebruikt (of een vergelijkbare implementatie daarvan). Als ik twee bestanden vergelijk die identiek zijn, afgezien van de newline op de laatste regel, dan krijg ik dit:
Code (php)
1
2
3
4
5
6
2
3
4
5
6
# diff document.txt document2.txt
3c3
< baz
\ No newline at end of file
---
> baz
3c3
< baz
\ No newline at end of file
---
> baz
Omdat in de output van diff de regel wél met een newline moet eindigen, geeft diff een extra melding waarmee wordt aangegeven dat de betreffende regel in het eerste document niet eindigt met een newline; het is anders onmogelijk om die versie exact te reproduceren. Blijkbaar wordt in dit geval die melding door de versiebeheertooling weer teruggekoppeld aan de gebruiker.
</poging om het gesprek weer on-topic te krijgen>
Gewijzigd op 07/09/2017 12:41:49 door Willem vp
Want ik ben niet onder in de indruk van je getallen. Daarnaast kan ik je hetzelfde verwijten over dat die andere link; die heb jij 'vast ook niet gelezen'.
Maar denk dat het enkel wat heen en weer gooien wordt van voorkeuren.
Gewijzigd op 07/09/2017 14:59:44 door Remco nvt