[Clarence]

90% av indenteringen ser likadan ut i välskriven kod som i Python kod (notera att du oftast har valmöjligheter i var du bryter raderna i python). Sen att du tycker det är en struntsak huruvida din kod är lätt läsbar eller ej, det låter jag dig stå för (det finns ca 43243242342 undersökningar som visar på att en konsekvent indentering leder till bättre läsbarhet). Själv tycker jag inte om att de ersatt andra avgränsningstecken med tvånget av indentering - men det tror jag är för att mina ögon är så vana vid C/PHP/Java/C#/etc-tecknena. Men det är ett tydligt val som faktiskt går väldigt bra ihop med faktiska egenskaper hos programmerare.

Sen vet jag inte om du är medveten om att en versions-taggning i din VCS leder till precis samma sak som en kompilerad binär. Det är en förhållandevis självklar process om man har acceptanstester eller liknande för varje lanserad version. Binären är lite svårare att ändra i annat än byta namn och i värsta fall göra den oidentifierbar eller obrukbar, taggningen är lättare att följa då man kan ta sig en titt i historyn om någon ändrat något (en tagg är en tagg är en tagg, den SKALL ej förändras. För versioner under arbete använder man branches.)

[Conny Westh]

Ursprungligen postat av Clarence

90% av indenteringen ser likadan ut i välskriven kod som i Python kod (notera att du oftast har valmöjligheter i var du bryter raderna i python). Sen att du tycker det är en struntsak huruvida din kod är lätt läsbar eller ej, det låter jag dig stå för (det finns ca 43243242342 undersökningar som visar på att en konsekvent indentering leder till bättre läsbarhet). Själv tycker jag inte om att de ersatt andra avgränsningstecken med tvånget av indentering - men det tror jag är för att mina ögon är så vana vid C/PHP/Java/C#/etc-tecknena. Men det är ett tydligt val som faktiskt går väldigt bra ihop med faktiska egenskaper hos programmerare.

Jag är för egen del ganska petig med indentering och placering av klamrar och parenteser i koden, men det stämde inte överens med vad Python anser trots att koden var tydligt indenterad/strukturerad. Men en teckenposition (dvs ett mellanslag för lite eller för mycket) hit eller dit så blev det körfel i runtime....

Python skrek högt om jag använde {tab} i stället för {space} för indenteringen, jag var tvungen att slå på automatisk omvandling till {space} för {tab}-tecknen för att det skulle gå att köra koden. Om jag minns rätt så är inte ens Cobol lika kinkig om man använder {tab} eller {space} vid indentering.

Ruby verkar vara betydligt mer generös med definitionen och toleransen av whitespace....

Jag har dock fortfarande problem med require i Ruby, får det bara inte att fungera.... Filerna ligger i samma katalog. Jag har PATH till Ruby Bin-katalog, alla annan kod jag testkör med Ruby funkar klockrent "load" funkar men inte "require". Vad gör jag för fel? Jag kör version 2.0.0p195 från 2013-05-14.

# File: Trig.rb
# Date: 2013-07-01
# Purpose: Trogonometry, include this namespace with require...

=begin
    This is a multiline comment in Ruby
=end

module Trig
  PI = 3.14159265358979

  def Trig.sin(x)
   # ..
   return x
  end
  def Trig.cos(x)
   # ..
   return x
  end
end

# File: TrigTest.rb
# Date: 2013-07-01
# Purpose: Trogonometry, Test to include Component with require...

=begin
    This is a multiline comment in Ruby
=end

#load "Trig.rb"
#load "Action.rb"

require("Trig")
require "Action"

y = Trig.sin(Trig::PI/4)
wrongdoing = Action.sin(Action::VERY_BAD)
puts(Trig::PI)

shit jag hittade felet, jag ska köra require_relative.... Då funkar det som jag tänkt....

[Clarence]

Ursprungligen postat av ConnyWesth

Jag är för egen del ganska petig med indentering och placering av klamrar och parenteser i koden, men det stämde inte överens med vad Python anser trots att koden var tydligt indenterad/strukturerad. Men en teckenposition (dvs ett mellanslag för lite eller för mycket) hit eller dit så blev det körfel i runtime....

Python skrek högt om jag använde {tab} i stället för {space} för indenteringen, jag var tvungen att slå på automatisk omvandling till {space} för {tab}-tecknen för att det skulle gå att köra koden. Om jag minns rätt så är inte ens Cobol lika kinkig om man använder {tab} eller {space} vid indentering.

Python gnäller väl bara om du blandar space-indentering och tabb-indentering? Och gör du det kan du få en rejäl röra mellan olika editorer då en tabs representation inte är fast medans spaces är det. Sen går det väl också lätt att stänga av denna varning om du vill skriva dålig kod.

Sen bör du ändå följa PEP8 om du skriver Python. Vilken säger åt dig att använda spaces (för att dess representation är konsekvent). Du ställer helt enkelt in din editor att använda spaces när du trycker på tab. Denna best practice återfinns i många style guidelines för en mängd språk.

Att du får runtime errors med rent felaktig indentering är väl rätt självklart. Om alla dina avgränsare är indentering så kan man väl förvänta sig att de är korrekta. Annat är väl ungefär som att tycka att ) ska kunna ersätta } i C# när det ändå inte finns någon starting (.